From cmom0020@endrino.cnice.mecd.es Mon Mar 1 13:12:00 2004 From: cmom0020@endrino.cnice.mecd.es (Carlos J. Montero Mendoza) Date: Mon, 1 Mar 2004 14:12:00 +0100 Subject: [OpenAFS] Chroot in afs? Message-ID: <001d01c3ff8e$c89b5d90$8c7b35c3@telematica.local> This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C3FF97.29EA2060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, friends I would like to know if is it possible to make a chroot over a user home = directory in afs. I=B4m planning to use afs for store all the counts of my system, but i = don=B4t want that the users can see the whole cell, only their = directories. Is it possible? Thanks very much. Carlos Montero ------=_NextPart_000_001A_01C3FF97.29EA2060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, friends
 
I would like to know if is = it possible to=20 make a chroot over a user home directory in afs.
I=B4m planning to use afs for store all = the counts of=20 my system, but i don=B4t want that the users can see the whole cell, = only their=20 directories. Is it possible? Thanks very much.
 
 
        = Carlos=20 Montero
------=_NextPart_000_001A_01C3FF97.29EA2060-- From openafs-info.lists@tisc.de Mon Mar 1 13:32:54 2004 From: openafs-info.lists@tisc.de (Tino Schwarze) Date: Mon, 1 Mar 2004 14:32:54 +0100 Subject: [OpenAFS] Chroot in afs? In-Reply-To: <001d01c3ff8e$c89b5d90$8c7b35c3@telematica.local> References: <001d01c3ff8e$c89b5d90$8c7b35c3@telematica.local> Message-ID: <20040301133254.GD4750@easy.in-chemnitz.de> On Mon, Mar 01, 2004 at 02:12:00PM +0100, Carlos J. Montero Mendoza wrote: > I would like to know if is it possible to make a chroot over a user home directory in afs. > I´m planning to use afs for store all the counts of my system, but i don´t want that the users can see the whole cell, only their directories. Is it possible? Thanks very much. A chroot in AFS is not possible since some special files are not supported: pipes, sockets and devices. In principle it would be possible but you usually need some of these files for a chroot environment to work. But there is another possibility: Just set the ACLs appropiately, then the users cannot see anything but their home directory (and the path leading to it). Bye, Tino. From mschmitt@inf.ethz.ch Mon Mar 1 14:05:10 2004 From: mschmitt@inf.ethz.ch (Marc Schmitt) Date: Mon, 01 Mar 2004 15:05:10 +0100 Subject: [OpenAFS] afsd: No check server daemon in client. Message-ID: <40434316.3060301@inf.ethz.ch> This is a multi-part message in MIME format. --------------080308000104010009060501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I did read the emails in the archive about the problem stated in the topic and tried all the suggestions: - re-install OpenAFS after having removed all RPMs (RedHat 7.3 system), tried 1.2.8, 1.2.9 and 1.2.10 - re-format the cache partition (after having zero'ed it) - run complete fsck on all filesystems - run `rpm -V` for all OpenAFS RPMs - run IBM Disk Fitness Tool on the disk where the system resides To no avail. Very odd. The machine had a crash, which seems to be the common prerequisite to trigger this issue. Upon reboot the usual fscks were done and everything (it's a DB server running mysql and postgresql) came up correctly except AFS. I've attached the debug output of afsd, maybe someone has an idea how to continue? If there is a possibility, I'd like to get it fixed w/o having to re-install the machine. TIA Marc --------------080308000104010009060501 Content-Type: application/x-bzip2; name="error.txt.bz2" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="error.txt.bz2" QlpoOTFBWSZTWeIIXpkFBAHfgGAQQOd/8i9n3wC////wYAt+D6goACqlQAAAAAAFAAHNMTAA mACYAATAAEw5piYAEwATAACYAAmHNMTAAmACYAATAAEw5piYAEwATAACYAAmCKIp6Ek8mo9T IyaNGI0PUZqP1Q9TNJvVAKkiATRomIEQmQQNMj0jxTTQ2pnc8Q2SB4EVFhpCpdao4gC94Qqv 2hUEO8VRdPJHdCAIqCFoAQFEQ5YEBXEYMYpBUqpnFEWpK3rKrohKiKCoIfpZ3UEOUf3q+u/G 7dk6RRFkN+HDhgTKw9w+rXe6lRHk5oSVVWhh53/ueOnLH+v0L+h7T06u8L9/s5P447/aeBoO 44/HKIrIEVk0oRzxeBWc8zmjzQOEFeUCSUKGOFrXs0ovoM77MGQvWtqoWFVQqGGFhdWeGDAU wFlKq4tYairS9QthYWsMBkLMMfFl8MMoYSmlaXhoKZ4DlgMLihQlSLWC2loWxrYXtDEUN5JJ DiiIbCCREPP74bBRF1oiCoIU2fLZbZ0gUDNdfdaqgRJCGIgkRCiEk9lZcbxJEn8BBIiFY4fc P/OwevgXH7h7iwvQ5Odok/UaC0KH+Hx9nw4ip74/tvhQYsI+u+Pt89NB3dfp9vGvQXGdxet/ /b9yfaMhlnxav1ptceoZwWGVa99sc23QUMIVC/MWFva1hUL2ajUXE4Goxy5DgcunrkKvlZaj 2szX9Mh++/TTPlhjW9DbYYawzZLrwyoY20qsMBrj203GHUXxU0zD+eO+8tWdDOkXHQa4DYZD t+HIZbZf6fQ5dDjHi+7DpaXGL654Djr1nUcDQeB2Fxcaj7/ULDUx99r2v5x+PGPnwNLu2HfY W49dMhhjy27kvQ2GefHYdBnbC2vvdhbpg255/EPUewtQr22745a9fTLLbTNv1sdvtOtEQVBD n6/ZUOfokPaFu0UFFRCL67nJaSISQh/IQSIhUfyFRjl1UmFVEVENXHhQSwCAoiHTN3DK0hXT xbIwEEiIZZYR1tCCREPwoURbeHQAnCKIt20BAURD7yICuWMgHdumgMCu223v35vGA3xllgWd H8EpBbeUkQkhCgiSqCqiVcQSIQhZgvt2+PFkbQPx0AdKHZ1oRzUA+AGbqs46I3/dI/nTBPyn MUmf4DfjEdD/6qSg10zes9aShSKKlR0357S+/6dcpEEiIfsfl3F/qOf57NBflOtsPxh6Y+R7 /0DcemQvJlbD05+b9OefQMNLX6TEUt+fGeQznKc/EPQWnlOdbjmwHZ/tjkicvpnne4vnijno K8binoKt0s6jJ+Wduw2xF+1OXXKi33iCRELTrwMa51xhbiVuywzRIkwhrckx3q6S/JMsuo5B tqGGFNZM5VJPre2lmslVET09cR38ZOlJ06VLb0LDplVrW9dBGvOIz4HS/ieBbF/ikRJjCDmP fqLYhwPCREm+uGgrHgWYjOEhiPd8+hUdhyiVUgqpCqqhVShSJLWecOyu/5jEY9O3Sw2FDXzV VbO7Dnk2bjrwPnKEhce3QVQsMkOFthr0RIk6T3guPjSR4JPUd7hXIf3uO4d9ZKlx+jTT3ZCw xy8297CwrQcSfI9OoyHoN4kiS3xnh9ZPl19qrCw5jjt7YdBtE5DIlx+jLb3zz3W6W1bDhasY tUt8vsFvmcqhGGWQkkm8SvbyL0KC4cq2DtJrtg1RVX2gtevlMLsvBJQ+tqFTBUvVq4oXiOdr Un3SVvDSGC8JQ7iuUKhpxjrQcajscCaDMai2LDSFycpJJbTO1YXyxv5GnbWEt6jTxhXx6puL 5D7Brg1HWhzrm1mnlUL9jp7Z8CqK9kmXNaTskRJUO9uwfKuXvzazn2oVvDXtGh4l/DGcSdYn cDqMdtr1D65+uhrnI2GU9unsLXGbJJgkmkJfPDBcjVEiTOUIJEQv5Fpvv3qHerj2rOY9PdWO 7Wajl19qzFC622PnTRaTlgiRJQgkRCpUeirQarDa4vDrhDT3tj00qCaQnOHi2X/WMeXRXObN hzpkXwyoc8UykDEcCiT3vkKDG0MRQyGodMhTalSRqKzFth4sFrULYObjvGA0e9WxFDnjyOl8 Aq8uLZDLWDLeVJjnFDlmmcqEBjSl7b3Gskk86WjGvcaMR33X5NJV0sLjVLa/xtqLvPgeMw4H 8K+IPf6Do8aQSoub71FUFfO9vuDvnknhbwN7JJEnp7Son+SSfPE+OnnwK1aN+/PBN9+fT1gy GW33mw8h6Ydta6jx+OAx5DAethcYBf5uMOdW+otz5jpn4HLPOwzt4FK4G690kiTkT48rTlx9 csB43ruKvmOQqDKUMuw2Hvz+7OJvDYYQ4q45tRkknKsdTQYChhNuUeuviFUXCdQ1peiovZMu ngWeCStEI9KFT5HnMY726joa88rZ8WV1S3pQratx3Fuw5TTl6jUaV4Gm3pe/XbK5sy5i/Z4u PXRzy3y1EVEc1Dl4Xd/TpytbLjEYqht3syroKFDlPG+OW+sn3ScTUcddMNeBfs62G2FKqVUq wstTDl37HoKmIZ0MKCZjDD2DWUftqXV58wtJmN9pNvI218EcWRtDih05E1Yu2FpXQevpDQcP xGdtekmIcD1ekmMPEJDuJ9o9saPirVVVI/Xt3HA2351MduTYMDcfK+YwkpXqLQsKFElUkrl0 h+wZ4Q9fppfRblJa0Hb3HPezWHaa5jK8x68DLbTb6eBg+fXnbQbayf1p/QrvDi3McfdO/XEZ k+bYCpHxzkWFD/8xQVkmU1lzqfsVBPA6X4AAEEDn+NIpAggAL+/eADABmAGxhkaaaZGEyME0 BgSoBAAAAAAJqpIyTaTUaaeU2p6ammjR6jcumnD9X01hRQPe79tppKSQcMUlWy627S8MbLvf ljwz1FFA2cufOKKB6RRQPQUUDHLoKKB7WunKyz8fOlFAzssroKKBlFFA6CigccZVIoG0UUDi KKBtFFA+Wqxj7CigaHWsV2rCUUDrziigeVur1s7OueYooHbpcrztNYooHtbfV5ThXu3vHdXx nla4m9jTjZ5fFjvb1IoHx3528UUD5rf/e7bi/zY27LZnhYycIryd9nyVD0JMOJTtKENFu4Ta LjGqrULJHFRdyRThQkLe5RiY --------------080308000104010009060501-- From bj_rui@hotmail.com Mon Mar 1 14:34:09 2004 From: bj_rui@hotmail.com (bj rui) Date: Mon, 01 Mar 2004 14:34:09 +0000 Subject: [OpenAFS] ishield files for openafs win client Message-ID: i'm wondering if someone can point me in the right direction for building my own installer for the openafs client for windows. i've got installshield adminstudio 5.5. do i need to build the openafs client from source or are there installshield files somewhere that i can grab? -bj _________________________________________________________________ Watch high-quality video with fast playback at MSN Video. Free! http://click.atdmt.com/AVE/go/onm00200365ave/direct/01/ From jaltman@columbia.edu Mon Mar 1 15:56:41 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Mon, 01 Mar 2004 10:56:41 -0500 Subject: [OpenAFS] ishield files for openafs win client In-Reply-To: References: Message-ID: <40435D39.9000206@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms030405030402020407060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We are moving away from the InstallShield installer. On the CVS HEAD are the sources for an installer built using the open source NSIS 2.0. src/WINNT/install/NSIS. There will soon be an MSI based installer as well. Although I cannot promise when that will be checked into CVS. Jeffrey Altman bj rui wrote: > i'm wondering if someone can point me in the right direction > for building my own installer for the openafs client for windows. > i've got installshield adminstudio 5.5. do i need to build the > openafs client from source or are there installshield files > somewhere that i can grab? > -bj --------------ms030405030402020407060409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMwMTE1NTY0MVowIwYJKoZIhvcNAQkEMRYEFOjcP9lKRUsS 3s2KsM4V4UuSAf7BMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAbHEfVGs6pKxnPOeCwzpgyO97iemm LAyXpzOUeEGlptyF4epU1u7gIiJkk7I/7NQie/4gBv49MHVEKcs4+2guZQBMKwSOLJm7l1uI 1JMNFicjDHYGxpyRT/PqrXo4VT/F1JuVhOFUunuufEWAgOrZWrOUPUE798H2qfi7tDNwsn/d FTarOG7ofTjBkNyfYQR9bgDURYJ1ImArWGMOlqWOhlFzGRaWdB0bdgAumMZxRHupOxbERibn 5Xp2sjysgW/PaF2kifdAmfc71xOVp8Oj234XcRQEI0aSP1OjeOOWSm42arWvujwFDGSLOu9i wjqGQ3weKGZiE55Sz9wRemxYTQAAAAAAAA== --------------ms030405030402020407060409-- From rra@stanford.edu Mon Mar 1 19:21:05 2004 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Mar 2004 11:21:05 -0800 Subject: [OpenAFS] Chroot in afs? In-Reply-To: <20040301133254.GD4750@easy.in-chemnitz.de> (Tino Schwarze's message of "Mon, 1 Mar 2004 14:32:54 +0100") References: <001d01c3ff8e$c89b5d90$8c7b35c3@telematica.local> <20040301133254.GD4750@easy.in-chemnitz.de> Message-ID: <87y8qk1ihq.fsf@windlord.stanford.edu> Tino Schwarze writes: > On Mon, Mar 01, 2004 at 02:12:00PM +0100, Carlos J. Montero Mendoza wrote: >> I would like to know if is it possible to make a chroot over a user >> home directory in afs. I=B4m planning to use afs for store all the >> counts of my system, but i don=B4t want that the users can see the whole >> cell, only their directories. Is it possible? Thanks very much. > A chroot in AFS is not possible since some special files are not > supported: pipes, sockets and devices. In principle it would be possible > but you usually need some of these files for a chroot environment to > work. On systems that support it, you can mount tmpfs over top of the chroot environment in AFS as the dev directory and then create the special devices inside that file system. That's one of the recommended solutions for doing chrooted ftp service out of AFS. --=20 Russ Allbery (rra@stanford.edu) From jhutz@cmu.edu Tue Mar 2 01:36:55 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 01 Mar 2004 20:36:55 -0500 Subject: [OpenAFS] Any plans to support multi-terabyte filesystems on solaris? In-Reply-To: <0HTR00K2TKMQRE@mailbox.slac.stanford.edu> References: <0HTR00K2TKMQRE@mailbox.slac.stanford.edu> Message-ID: <48550000.1078191415@liandra.pc.cs.cmu.edu> On Friday, February 27, 2004 14:18:26 -0800 Renata Maria Dart wrote: > Hello, is there a plan to support multi-terabyte /vicep partitions on > inode fileservers (that is, NOT namei fileservers) which became > possible with solaris 9 update 4? This new multi-terabyte support > in solaris involves a change to the magic number in the superblock. Well, it's more than just a magic number -- there are real changes to the filesystem structure, and according to my contact at Sun, journalling must be enabled on such filesystems. So no, at present, the inode fileserver does not support multi-terabyte vice partitions. We're looking into working with Sun to get this working, but we're still too early in that process to make any promises. In the meantime, the only alternatives are using smaller vice partitions or running the namei fileserver. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From Renata Maria Dart Tue Mar 2 01:53:40 2004 From: Renata Maria Dart (Renata Maria Dart) Date: Mon, 01 Mar 2004 17:53:40 -0800 (PST) Subject: [OpenAFS] Any plans to support multi-terabyte filesystems on solaris? Message-ID: <0HTX001KXELGCW@mailbox.slac.stanford.edu> Hi, thanks very much for the feedback. As far as the journalling goes, I understood that logging is on by default with multi-terabyte filesystems, but that it can be turned off with the nologging option. Of course, logging is turned on by default because to fsck a 1tb+ filesystem would probably take an unpleasantly long time. Again, thanks for letting me know where you are at. -Renata >Date: Mon, 01 Mar 2004 20:36:55 -0500 >From: Jeffrey Hutzelman >Subject: Re: [OpenAFS] Any plans to support multi-terabyte filesystems on solaris? >To: Renata Maria Dart , openafs-info@openafs.org >MIME-version: 1.0 >Content-transfer-encoding: 7bit >Content-disposition: inline >Delivered-to: openafs-info@openafs.org >X-BeenThere: openafs-info@openafs.org >X-Mailman-Version: 2.0.4 >X-PMX-Version: 4.5.0.90627, Antispam-Core: 4.0.4.92622, Antispam-Data: 2004.3.1.93161 >List-Post: >List-Subscribe: , >List-Unsubscribe: , >List-Archive: >List-Help: >List-Id: OpenAFS Info/Discussion > > > >On Friday, February 27, 2004 14:18:26 -0800 Renata Maria Dart > wrote: > >> Hello, is there a plan to support multi-terabyte /vicep partitions on >> inode fileservers (that is, NOT namei fileservers) which became >> possible with solaris 9 update 4? This new multi-terabyte support >> in solaris involves a change to the magic number in the superblock. > >Well, it's more than just a magic number -- there are real changes to the >filesystem structure, and according to my contact at Sun, journalling must >be enabled on such filesystems. > >So no, at present, the inode fileserver does not support multi-terabyte >vice partitions. We're looking into working with Sun to get this working, >but we're still too early in that process to make any promises. In the >meantime, the only alternatives are using smaller vice partitions or >running the namei fileserver. > >-- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA > >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info Renata Dart | renata@SLAC.Stanford.edu Stanford Linear Accelerator Center | 2575 Sand Hill Road, MS 97 | (650) 926-2848 (office) Stanford, California 94025 | (650) 926-3329 (fax) From ian@assv.net Tue Mar 2 15:13:43 2004 From: ian@assv.net (Ian Delahorne) Date: 02 Mar 2004 16:13:43 +0100 Subject: [OpenAFS] qmail and user mail accounts in AFS In-Reply-To: <18564.1077561256@www25.gmx.net> References: <18564.1077561256@www25.gmx.net> Message-ID: "Michael Raitza" writes: > I've set up an AFS cell housing the user accounts. Now I ran into trouble > with qmail delivering mail improperly. I've tried to find information about > that issue in the archives but there's nothing very specific. > > Has anyone got qmail working with delivering mail directly into AFS? Hasn't this been tried, rejected, and replaced with IMAP at most places? -- /Ian D ian@assv.net - www.assv.net From gregory.touretsky@intel.com Tue Mar 2 17:44:58 2004 From: gregory.touretsky@intel.com (Touretsky, Gregory) Date: Tue, 2 Mar 2004 19:44:58 +0200 Subject: [OpenAFS] Parsing "vos dump" output Message-ID: <8B61E4522DDD274289E7AE1293EFE44E02F99469@hasmsx402.iil.intel.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C4007E.1474AB45 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, is there any utility that would allow us to extract files (even without ACLs) from the vos dump output? Gregory Touretsky Intel Israel Engineering Computing Unix Server Platforms gregory.touretsky@intel.com > (+) 972-4-865-6377, Fax: 04-865-5999 iNET: 465-6377, M/S: IDC-1B ------_=_NextPart_001_01C4007E.1474AB45 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Parsing "vos dump" output

Hi,

   is there any utility that = would allow us to extract files (even without ACLs) from the vos dump = output?

Gregory = Touretsky
Intel Israel = Engineering Computing
Unix Server = Platforms
gregory.touretsky@intel.com
(+) 972-4-865-6377, = Fax: 04-865-5999
iNET: 465-6377, = M/S: IDC-1B


------_=_NextPart_001_01C4007E.1474AB45-- From shadow@dementia.org Tue Mar 2 21:23:47 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Tue, 2 Mar 2004 16:23:47 -0500 (EST) Subject: [OpenAFS] Parsing "vos dump" output In-Reply-To: <8B61E4522DDD274289E7AE1293EFE44E02F99469@hasmsx402.iil.intel.com> References: <8B61E4522DDD274289E7AE1293EFE44E02F99469@hasmsx402.iil.intel.com> Message-ID: On Tue, 2 Mar 2004, Touretsky, Gregory wrote: > Hi, > > is there any utility that would allow us to extract files (even > without ACLs) from the vos dump output? dumptool. unofficial version in src/tests in your openafs distribution. From Christophe.BERNARD@cmm.ensmp.fr Wed Mar 3 07:15:54 2004 From: Christophe.BERNARD@cmm.ensmp.fr (Christophe BERNARD) Date: Wed, 3 Mar 2004 08:15:54 +0100 (CET) Subject: [OpenAFS] AFS client not working any more with TABs in CellServDB Message-ID: Hello. I have been running an AFS server for a while. The server is multi-homed, and used to be working. Recently, I noticed that the AFS server cannot mount itself any more. Before considering asking to the list, I read the archives, searched google for anything sensible, and tried a LOT of workarounds, and got really desperate. At startup, the afs client daemon failed, giving error messages like these: afs: Lost contact with file server 10.0.0.1 in cell domain.com (all multi-homed ip addresses down for the server) and later afs: file server 10.0.0.1 in cell domain.com is back up (multi-homed address; other same-host interfaces may still be down) afsd -verbose said: afsd: Mounting the AFS root on '/afs', flags: 0. afsd: Can't mount AFS on /afs(22) This was a client problem: all other clients still could access the AFS filesystem. I checked name resolution, the hosts file, all NetCOnfig NetInfo files, everything was OK, tried to clean-up the cache directory. Still "Can't mount AFS". After a lengthy comparison on config files between working clients and the server's client config, I finally found the fix, which is worth mentioning: the CellServDB file in /usr/vice/etc had a [TAB] character, like this: >domain.com[TAB]#cell name 10.0.0.1 #afs.domain.com I replaced the [TAB] with spaces, and YES! it worked. So my 2c suggestion to the openafs team: would it be possible to make CellServDB file parsing by the client a wee more robust, like correctly skipping tabs like spaces, and even possibly logging warnings when not-ascii characters are met? Anyways, many thanks for the great piece of software, Regards, Christophe PS: using redhat/linux -- Christophe BERNARD - Centre de Morphologie Mathématique École des Mines de Paris - 35, rue Saint-Honoré - 77305 Fontainebleau cedex tél +33-1-64694775 - fax +33-1-64694707 email bernard@cmm.ensmp.fr - http://cmm.ensmp.fr From jarausch@igpm.rwth-aachen.de Wed Mar 3 09:54:46 2004 From: jarausch@igpm.rwth-aachen.de (Helmut Jarausch) Date: Wed, 03 Mar 2004 10:54:46 +0100 (CET) Subject: [OpenAFS] openafs-1.3.52 - please apply this patch Message-ID: <20040303095446.0F822FF5CC@numa-i.igpm.rwth-aachen.de> Hi, as Hans-Werner Paulsen pointed out already Jan 10, 2003 Linux doesn't allow fsync'ing a raw tape device which is a character device. So please apply the following patch modified to use something like AFS_Linux_ENV --- openafs-1.3.52/src/usd/usd_file.c.orig 2004-03-03 10:16:48.000000000 +0100 +++ openafs-1.3.52/src/usd/usd_file.c 2004-03-03 10:07:24.000000000 +0100 @@ -308,7 +308,8 @@ code = usd_FileIoctl(usd, USD_IOCTL_GETTYPE, &mode); if (code == 0) { if (S_ISBLK(mode) -#ifndef AFS_AIX_ENV +/*HJ #ifndef AFS_AIX_ENV */ +#if 0 /* on AIX3.1 can't fsync raw disk device */ || S_ISCHR(mode) #endif Many thanks, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From jhutz@cmu.edu Wed Mar 3 10:47:30 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 03 Mar 2004 19:47:30 +0900 Subject: [OpenAFS] AFS client not working any more with TABs in CellServDB In-Reply-To: References: Message-ID: <27870000.1078310850@liandra.pc.cs.cmu.edu> On Wednesday, March 03, 2004 08:15:54 +0100 Christophe BERNARD wrote: > At startup, the afs client daemon failed, giving error messages like > these: > > afs: Lost contact with file server 10.0.0.1 in cell domain.com (all > multi-homed ip addresses down for the server) > > and later > > afs: file server 10.0.0.1 in cell domain.com is back up (multi-homed > address; other same-host interfaces may still be down) These messages would seem to indicate that your CellSerbDB entry was correctly parsed, and that the cache manager had some trouble talking to the fileserver (not the vldb server!) on 10.0.0.1. If the CellServDB parse had failed, you would not have seen such messages. > I replaced the [TAB] with spaces, and YES! it worked. So my 2c suggestion > to the openafs team: would it be possible to make CellServDB file parsing > by the client a wee more robust, like correctly skipping tabs like spaces, Parsing of CellServDB lines uses sscanf, and is pretty permissive. Any whitespace (or no whitespace) is permitted; tabs will work; spaces are not required. > and even possibly logging warnings when not-ascii characters are met> Non-ASCII characters are permitted, in the comments. Of course they make no sense in IP addresses.... Can you reproduce the problem by changing the space back to a tab? -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From mschmitt@inf.ethz.ch Wed Mar 3 11:26:02 2004 From: mschmitt@inf.ethz.ch (Marc Schmitt) Date: Wed, 03 Mar 2004 12:26:02 +0100 Subject: [OpenAFS] afsd: No check server daemon in client. In-Reply-To: <20040301150009.GE4750@easy.in-chemnitz.de> References: <40434316.3060301@inf.ethz.ch> <20040301150009.GE4750@easy.in-chemnitz.de> Message-ID: <4045C0CA.8050909@inf.ethz.ch> Hi Tino, Thanks for the hint. I did --rebuild the openafs-1.2.11-rh7.3.1.src.rpm on the machine where the problems exists. No build problems, no install problems but AFS does not start, still the same errors. Did you build from source or SRPM (although I don't expect that to make a difference...)? Marc Tino Schwarze wrote: >On Mon, Mar 01, 2004 at 03:05:10PM +0100, Marc Schmitt wrote: > > > >>I did read the emails in the archive about the problem stated in the >>topic and tried all the suggestions: >>- re-install OpenAFS after having removed all RPMs (RedHat 7.3 system), >>tried 1.2.8, 1.2.9 and 1.2.10 >>- re-format the cache partition (after having zero'ed it) >>- run complete fsck on all filesystems >>- run `rpm -V` for all OpenAFS RPMs >>- run IBM Disk Fitness Tool on the disk where the system resides >> >>To no avail. Very odd. The machine had a crash, which seems to be the >>common prerequisite to trigger this issue. Upon reboot the usual fscks >>were done and everything (it's a DB server running mysql and postgresql) >>came up correctly except AFS. >> >>I've attached the debug output of afsd, maybe someone has an idea how to >>continue? If there is a possibility, I'd like to get it fixed w/o having >>to re-install the machine. >> >> > >I came across this problem several times (on SuSE) and without knowing >the exact cause, recompiling the AFS stuff used to help. It's odd... > >HTH! Tino. > > > From mschmitt@inf.ethz.ch Wed Mar 3 11:48:34 2004 From: mschmitt@inf.ethz.ch (Marc Schmitt) Date: Wed, 03 Mar 2004 12:48:34 +0100 Subject: [OpenAFS] Fedora Legacy Project and OpenAFS Message-ID: <4045C612.5040207@inf.ethz.ch> Derek, You have probably heard of the Fedora Legacy Project: http://www.fedoralegacy.org/ Yesterday, they released a kernel upgrade for RedHat 7.2, 7.3 and 8: https://www.redhat.com/archives/fedora-legacy-announce/2004-March/msg00000.html RedHat 7.3 and 8 are still listed on the download page for OpenAFS. I was wondering if you would consider adding the legacy errata kernels to your RPM build environment for 7.3 and 8, in case your plans were to continue supporting those two releases for upcoming OpenAFS releases? I could --rebuild openafs-1.2.11-rh7.3.1.src.rpm with kernel-source-2.4.20-30.7.legacy.i386.rpm w/o any problems. Marc From warlord@MIT.EDU Wed Mar 3 11:53:33 2004 From: warlord@MIT.EDU (Derek Atkins) Date: Wed, 03 Mar 2004 06:53:33 -0500 Subject: [OpenAFS] Fedora Legacy Project and OpenAFS In-Reply-To: <4045C612.5040207@inf.ethz.ch> (Marc Schmitt's message of "Wed, 03 Mar 2004 12:48:34 +0100") References: <4045C612.5040207@inf.ethz.ch> Message-ID: Hi, Marc Schmitt writes: > Derek, > > You have probably heard of the Fedora Legacy Project: > http://www.fedoralegacy.org/ Nope, I hadn't heard of it... > Yesterday, they released a kernel upgrade for RedHat 7.2, 7.3 and 8: > https://www.redhat.com/archives/fedora-legacy-announce/2004-March/msg00000.html *sighs* Well, I'll think about it. > RedHat 7.3 and 8 are still listed on the download page for OpenAFS. I > was wondering if you would consider adding the legacy errata kernels > to your RPM build environment for 7.3 and 8, in case your plans were > to continue supporting those two releases for upcoming OpenAFS > releases? Well, my intention was to drop support in future releases, but that sort of presumes a 1.4 release as opposed to a 1.2 release. I suppose I can continue to support 7.3 and above. > I could --rebuild openafs-1.2.11-rh7.3.1.src.rpm with > kernel-source-2.4.20-30.7.legacy.i386.rpm w/o any problems. Good to know. I presume you tested whether the previous version didn't work with the new kernel? > Marc -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From hgai@ecs.syr.edu Wed Mar 3 16:13:55 2004 From: hgai@ecs.syr.edu (Hongliang Gai) Date: Wed, 3 Mar 2004 11:13:55 -0500 (EST) Subject: [OpenAFS] build reauth problem with 'krb.h' Message-ID: Hi All, I have been trying to build reauth for Redhat 8.0 but failed. I need help. I have downloaded reauth from ftp://ftp.andrew.cmu.edu/pub/AFS-Tools/reauth-0.0.6.tar.gz and openafs-devel-1.2.11-rh8.0.1.i386.rpm from openafs.org for the included afs lib headers. And krb4 headers exist in the dir: ------------------------------------------------ %ls /usr/kerberos/include/kerberosIV/ des.h kadm.h krb_err.h krb.h mit-copyright.h ------------------------------------------------ How can I correctly include krb.h in the build process? I have tried some different ways shown as below, they all failed... Thanks, Hongliang I did follows according to help messeges in the archive mails: 1 change to in reauth.c 2. configure --with-afs=/usr --with-krb4=/usr/kerberos And the following error message: -------------------------------------------------------------- ./configure --with-afs=/usr --with-krb4=/usr/kerberos loading cache ./config.cache checking for mkdirhier... (cached) /usr/bin/X11/mkdirhier using /usr/bin/X11/mkdirhier checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for a BSD compatible install... (cached) /usr/bin/install -c checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking for stdlib.h... (cached) yes checking for strings.h... (cached) yes checking for malloc.h... (cached) yes checking for unistd.h... (cached) yes checking for connect... (cached) yes checking for gethostbyname... (cached) yes checking for system network libs... using checking for krb_mk_req in -lkrb... no configure: error: Kerberos library not found ---------------------------------------------------------------- Then I changed to configure without krb4 option and use in reauth.c, 'configure' seems ok. But when I 'make', it say krb.h:no such file. the error message: ---------------------------------------------------------------- # make gcc -g -O2 -DHAVE_CONFIG_H -I/usr/include -c -o reauth.o reauth.c cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory reauth.c:19:17: krb.h: No such file or directory reauth.c: In function `key_to_key': reauth.c:54: parse error before "C_Block" reauth.c:56: `des_cblock' undeclared (first use in this function) reauth.c:56: (Each undeclared identifier is reported only once reauth.c:56: for each function it appears in.) reauth.c:56: warning: passing arg 1 of `memcpy' makes pointer from integer without a cast reauth.c: In function `logme': reauth.c:73: `REALM_SZ' undeclared (first use in this function) reauth.c:75: `CREDENTIALS' undeclared (first use in this function) reauth.c:75: parse error before "c" reauth.c:76: `C_Block' undeclared (first use in this function) reauth.c:85: `key_proc_t' undeclared (first use in this function) reauth.c:85: parse error before "authfunc" reauth.c:112: `afskey' undeclared (first use in this function) reauth.c:113: `mitkey' undeclared (first use in this function) reauth.c:121: `DEFAULT_TKT_LIFE' undeclared (first use in this function) reauth.c:129: `krb_err_txt' undeclared (first use in this function) reauth.c:142: `c' undeclared (first use in this function) reauth.c: In function `main': reauth.c:221: `REALM_SZ' undeclared (first use in this function) make: *** [reauth.o] Error 1 ----------------------------------------------------------------- If I copy all the krb header files to /usr/include/kerberosIV/, and configure and make, it has the same error message as above. From openafs@gnosys.biz Wed Mar 3 16:26:06 2004 From: openafs@gnosys.biz (Kevin) Date: Wed, 3 Mar 2004 11:26:06 -0500 Subject: [OpenAFS] Kerberos V, users, passwd, shadow, alternatives Message-ID: <200403031126.06701.openafs@gnosys.biz> Hi All- I've posted a few questions in the last month or so and thanks to those who replied, I'm now up and running with a single AFS server running a SuSE 9 distro with self-built version 1.2.11 of OpenAFS (SuSE 9 ships with 1.2.10) that uses a self-built MIT Kerberos 5, v1.3.1 (SuSE 9 ships with heimdal) system for authentication. Thank you for the help! While I'll admit to not having read all of the documentation yet, I have read all of the conceptual stuff, the QBG, and portions of the administrator's reference and administrator's guide. Naturally, I'm learning as I go and studying the docs very carefully, but there's one issue that I'd like to ask about because the docs I've read thus far don't mention it: the Linux password shadow suite of programs. I searched the archive for this subject and saw a few mentions of it, but none recently and none in much depth (except in regards to NIS which I'm not using and would prefer avoiding unless it makes alot of sense to use it). As would most people I guess, I'd like to have all AFS user data (stuff found in /etc/passwd (login shell, unix uid, unix gid, Name, home directory), /etc/shadow (password and related data), the kerberos database (principals and their privileges), openafs acls, openafs uid, etc.) be centrally located, universally accessible, and easy to maintain. Based on the docs I've read thus far, I should be making a common /etc/passwd file on AFS and merging it with each client machine's /etc/passwd file whenever a change is made to the AFS /etc/passwd file using cron or something. My question(s) is/are: Is that still the best way to do this? And what about /etc/shadow? Do I need to write a script for shadow that is similar to that found in the docs on merging the AFS /etc/passwd file with each client machine's /etc/passwd file? For my purposes, except for each client machine's root account, I'd like to have all users be authenticated from a single (perhaps replicated) source, and not have any user accounts on each client machine's local authentication source (no local users except root---only Kerberos users for the network). Or even, is there a way to make a "network superuser" that would have root access to all client computers? Or is that a bad idea? What do people do for the root password on each client machine when there are hundreds (or more) client machines? Make them all the same? Keep a database of machines and their root passwords handy? Just curious... I'm sure someone else besides me has encountered this issue. Care to share your ideas on the best way to do this? I guess LDAP is an option, but I haven't done much with that. What are others in similar circumstances doing? Oh, and as a final complication, what about throwing windows machines into the fray? I maintain several Samba PDCs and their associated networks, and that seems to offer a pretty good (though not ideal) model. Is it possible to do something similar with Kerberos and OpenAFS. I know there is a way (with native Windows code) to have the Windows box be a member of a Kerberos Realm and have OS check an MIT Kerberos KDC for login authentication, but it doesn't scale well (requires changing each client machine's list of users with every change in the network user list). Aside from that, am I looking at a definite two-step login process for windows machines authenticating against an MIT kerberos database and accessing OpenAFS volumes? Many thanks for any thoughts. -Kevin From openafs-info.lists@tisc.de Wed Mar 3 16:41:52 2004 From: openafs-info.lists@tisc.de (Tino Schwarze) Date: Wed, 3 Mar 2004 17:41:52 +0100 Subject: [OpenAFS] afsd: No check server daemon in client. In-Reply-To: <4045C0CA.8050909@inf.ethz.ch> References: <40434316.3060301@inf.ethz.ch> <20040301150009.GE4750@easy.in-chemnitz.de> <4045C0CA.8050909@inf.ethz.ch> Message-ID: <20040303164152.GJ4750@easy.in-chemnitz.de> On Wed, Mar 03, 2004 at 12:26:02PM +0100, Marc Schmitt wrote: > Thanks for the hint. I did --rebuild the openafs-1.2.11-rh7.3.1.src.rpm > on the machine where the problems exists. No build problems, no install > problems but AFS does not start, still the same errors. Did you build > from source or SRPM (although I don't expect that to make a difference...)? I think so. It's been quite a while since I came across this problem. But I don't have any clue what the cause is. :-( Bye, Tino. From mschmitt@inf.ethz.ch Wed Mar 3 16:54:27 2004 From: mschmitt@inf.ethz.ch (Marc Schmitt) Date: Wed, 03 Mar 2004 17:54:27 +0100 Subject: [OpenAFS] Fedora Legacy Project and OpenAFS In-Reply-To: References: <4045C612.5040207@inf.ethz.ch> Message-ID: <40460DC3.2060201@inf.ethz.ch> Derek Atkins wrote: >Marc Schmitt writes: > > >>I could --rebuild openafs-1.2.11-rh7.3.1.src.rpm with >>kernel-source-2.4.20-30.7.legacy.i386.rpm w/o any problems. >> >> > >Good to know. I presume you tested whether the previous version >didn't work with the new kernel? > Yes... meanwhile. :) I'm still using 1.2.10 everywhere, which I knew wouldn't work. But 1.2.11 works fine. I tried on a box running kernel 2.4.20-30.7.legacysmp, it loads libafs-2.4.20-27.7-i686.mp.o. I think it's safe to assume that it will work with 2.4.20-30.7.legacy, too. Marc From bacchi@rpi.edu Wed Mar 3 17:04:25 2004 From: bacchi@rpi.edu (Andrew Bacchi) Date: 03 Mar 2004 12:04:25 -0500 Subject: [OpenAFS] Kerberos V, users, passwd, shadow, alternatives In-Reply-To: <200403031126.06701.openafs@gnosys.biz> References: <200403031126.06701.openafs@gnosys.biz> Message-ID: <1078333465.9764.36.camel@boreal.netel.rpi.edu> Kevin, You certainly haven't left any questions out. My replies below. It should work for Suse. On Wed, 2004-03-03 at 11:26, Kevin wrote: > > As would most people I guess, I'd like to have all AFS > user data (stuff found in /etc/passwd (login shell, > unix uid, unix gid, Name, home directory), /etc/shadow > (password and related data), the kerberos database > (principals and their privileges), openafs acls, > openafs uid, etc.) be centrally located, universally > accessible, and easy to maintain. > > Based on the docs I've read thus far, I should be > making a common /etc/passwd file on AFS and merging it > with each client machine's /etc/passwd file whenever a > change is made to the AFS /etc/passwd file using cron > or something. > > My question(s) is/are: > > Is that still the best way to do this? > > And what about /etc/shadow? Do I need to write a > script for shadow that is similar to that found in the > docs on merging the AFS /etc/passwd file with each > client machine's /etc/passwd file? > > For my purposes, except for each client machine's root > account, I'd like to have all users be authenticated > from a single (perhaps replicated) source, and not > have any user accounts on each client machine's local > authentication source (no local users except > root---only Kerberos users for the network) . May I suggest researching LDAP. It will provide the central data source you are looking for. You can store all users, hosts, groups, etc. in the LDAP database and access that at login to provide more info than /etc/passwd. Very adaptable. Also, pam modules (pluggable authentication module) will enable you to limit users/groups access to any particular machine. Works nicely in concert with LDAP. > > Or even, is there a way to make a "network superuser" > that would have root access to all client computers? > Or is that a bad idea? What do people do for the root > password on each client machine when there are > hundreds (or more) client machines? Make them all the > same? Keep a database of machines and their root > passwords handy? Just curious... Pam again. Or if you have a need to update client machines on a regular basis, 'package' can be compiled into OpenAFS (see the Transarc documentation for this). This will enable you to push out config changes, upgrades, etc to local clients. Not a good idea to keep root passwords lying around. > > I'm sure someone else besides me has encountered this > issue. Care to share your ideas on the best way to do > this? I guess LDAP is an option, but I haven't done > much with that. What are others in similar > circumstances doing? LDAP isn't as difficult as getting AFS and Kerb5 working together. You've already done the hard part. You won't have difficulty with LDAP. Just don't plan on LDAP for auth, keep the kerberos for ticket granting. -- Facade: Provide a unified interface to a set of interfaces in a subsystem. Andrew Bacchi Staff Systems Programmer Rensselaer Polytechnic Institute phone: 518 276-6415 fax: 518 276-2809 http://www.rpi.edu/~bacchi/ From D.P.Miller@lse.ac.uk Wed Mar 3 17:32:42 2004 From: D.P.Miller@lse.ac.uk (David Miller) Date: Wed, 03 Mar 2004 17:32:42 +0000 Subject: [OpenAFS] Kerberos V, users, passwd, shadow, alternatives In-Reply-To: <1078333465.9764.36.camel@boreal.netel.rpi.edu> References: <200403031126.06701.openafs@gnosys.biz> <1078333465.9764.36.camel@boreal.netel.rpi.edu> Message-ID: <404616BA.7040801@lse.ac.uk> >LDAP isn't as difficult as getting AFS and Kerb5 working together. >You've already done the hard part. You won't have difficulty with >LDAP. Just don't plan on LDAP for auth, keep the kerberos for ticket >granting. > > > I aggree. Use LDAP. Most distros make it pretty easy to migrate and setup ldap. it also has good, easy to setup replication and fail-over support on the clients (nss-ldap) I then wrote some simple perl scripts to control user administration in ldap+kerberos+openafs (create ldap entries, create kerberos user, create afs volume, etc). I've found this documentation pretty good..its debian specific, but most of it is the same http://www.metaconsultancy.com/whitepapers/ldap.htm http://www.metaconsultancy.com/whitepapers/ldap-linux.htm For the full setup (OpenAFS, LDAP, kerberos 5) http://www.bayour.com/LDAPv3-HOWTO.html From jds@soltis.cc Wed Mar 3 22:33:08 2004 From: jds@soltis.cc (jds) Date: Wed, 3 Mar 2004 16:33:08 -0600 Subject: [OpenAFS] start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl Message-ID: <20040303223230.M17878@soltis.cc> Hi: Iam compile OpenAFS 1.2.11-fc1 with kernel 2.4.22-1.2174.nptl is OK the problems is when start the client AFS recive the messages: [root@angelinux modload]# service afs start Found libafs-2.4.22-1.2174.nptl-i686.o from SymTable... Loading... Starting AFS services..... /etc/init.d/afs: line 305: 3300 Segmentation fault /usr/vice/etc/afsd ${AFSD_OPTIONS} [root@angelinux modload]# lsmod Module Size Used by Tainted: PF libafs-2.4.22-1.2174.nptl-i686 483360 0 (unused) parport_pc 18756 1 (autoclean) etc,etc In log messages: Starting AFS cache scan...Can't open inode 135536 Unable to handle kernel paging request at virtual address ffffffff printing eip: f093e1b0 *pde = 00002067 *pte = 00000000 Oops: 0002 libafs-2.4.22-1.2174.nptl-i686 parport_pc lp parport autofs tg3 floppy sg keybdev hid ehci-hcd usb-uhci usbcore mousedev input i830 agpgart reiserfs ata_piix CPU: 0 EIP: 0060:[] Tainted: PF EFLAGS: 00010282 EIP is at osi_Panic [libafs-2.4.22-1.2174.nptl-i686] 0x20 (2.4.22-1.2174.nptl) eax: 00000018 ebx: e7bd2580 ecx: 00000001 edx: e80d6000 esi: ea666b80 edi: ea666c08 ebp: 00000400 esp: e80d7c14 ds: 0068 es: 0068 ss: 0068 Process afsd (pid: 3300, stackpage=e80d7000) Stack: f095c03c 00021170 c0341640 c0341640 ea666b80 ea666c08 c19b4800 f0948130 f095c03c 00021170 c0341640 c0341640 ef724c10 00000000 00000000 00000000 f0b5b000 00000000 00000001 f090e52d 00021170 00000000 00000ce4 00000ce4 Call Trace: [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] 0xe0c (0xe80d7c14) [] osi_UFSOpen [libafs-2.4.22-1.2174.nptl-i686] 0x120 (0xe80d7c30) [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] 0xe0c (0xe80d7c34) [] afs_InitCacheFile [libafs-2.4.22-1.2174.nptl-i686] 0x10d (0xe80d7c60) [] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c7c) [] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c80) [] afs_InitVolumeInfo [libafs-2.4.22-1.2174.nptl-i686] 0x5b (0xe80d7c90) [] afs_syscall_call [libafs-2.4.22-1.2174.nptl-i686] 0x5ce (0xe80d7cb0) [] activate_page [kernel] 0xab (0xe80d7ce4) [] getblk [kernel] 0x59 (0xe80d7d00) [] bread [kernel] 0x20 (0xe80d7d24) [] is_tree_node [reiserfs] 0x74 (0xe80d7d40) [] search_by_key [reiserfs] 0x5b1 (0xe80d7d54) [] journal_end [reiserfs] 0x27 (0xe80d7d94) [] reiserfs_dirty_inode [reiserfs] 0x7e (0xe80d7da8) [] search_by_entry_key [reiserfs] 0xc8 (0xe80d7dd4) [] pathrelse [reiserfs] 0x21 (0xe80d7df4) [] reiserfs_readdir [reiserfs] 0x3c7 (0xe80d7e04) [] __alloc_pages [kernel] 0x64 (0xe80d7e44) [] __alloc_pages [kernel] 0x64 (0xe80d7e68) [] vm_enough_memory [kernel] 0x33 (0xe80d7e84) [] rb_insert_color [kernel] 0x8f (0xe80d7ea0) [] do_wp_page [kernel] 0x4d (0xe80d7ebc) [] handle_mm_fault [kernel] 0xf9 (0xe80d7ee0) [] do_page_fault [kernel] 0x138 (0xe80d7f0c) [] afs_syscall [libafs-2.4.22-1.2174.nptl-i686] 0x190 (0xe80d7f40) [] do_page_fault [kernel] 0x0 (0xe80d7fb0) [] system_call [kernel] 0x33 (0xe80d7fc0) Code: c6 05 ff ff ff ff 2a 83 c4 1c c3 90 8d 74 26 00 b8 1e bd 95 with kernel 2.4.22-2166 and is the same version OpenAFS working good and startup client AFS good. Helpme please. From warlord@MIT.EDU Wed Mar 3 22:33:38 2004 From: warlord@MIT.EDU (Derek Atkins) Date: Wed, 03 Mar 2004 17:33:38 -0500 Subject: [OpenAFS] start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040303223230.M17878@soltis.cc> (jds@soltis.cc's message of "Wed, 3 Mar 2004 16:33:08 -0600") References: <20040303223230.M17878@soltis.cc> Message-ID: What kind of filesystem is /usr/vice/cache? It looks like it might be reiserfs. If so, that's your problem: you cannot put an AFS Cache on reiserfs. Change the file type to ext{2,3}. -derek "jds" writes: > Hi: Iam compile OpenAFS 1.2.11-fc1 with kernel 2.4.22-1.2174.nptl is OK > > the problems is when start the client AFS recive the messages: > > > [root@angelinux modload]# service afs start > Found libafs-2.4.22-1.2174.nptl-i686.o from SymTable... Loading... > Starting AFS services..... > /etc/init.d/afs: line 305: 3300 Segmentation fault /usr/vice/etc/afsd > ${AFSD_OPTIONS} > [root@angelinux modload]# lsmod > Module Size Used by Tainted: PF > libafs-2.4.22-1.2174.nptl-i686 483360 0 (unused) > parport_pc 18756 1 (autoclean) > etc,etc > > In log messages: > Starting AFS cache scan...Can't open inode 135536 > Unable to handle kernel paging request at virtual address ffffffff > printing eip: > f093e1b0 > *pde = 00002067 > *pte = 00000000 > Oops: 0002 > libafs-2.4.22-1.2174.nptl-i686 parport_pc lp parport autofs tg3 floppy sg > keybdev hid ehci-hcd usb-uhci usbcore mousedev input i830 agpgart reiserfs > ata_piix > CPU: 0 > EIP: 0060:[] Tainted: PF > EFLAGS: 00010282 > > EIP is at osi_Panic [libafs-2.4.22-1.2174.nptl-i686] 0x20 (2.4.22-1.2174.nptl) > eax: 00000018 ebx: e7bd2580 ecx: 00000001 edx: e80d6000 > esi: ea666b80 edi: ea666c08 ebp: 00000400 esp: e80d7c14 > ds: 0068 es: 0068 ss: 0068 > Process afsd (pid: 3300, stackpage=e80d7000) > Stack: f095c03c 00021170 c0341640 c0341640 ea666b80 ea666c08 c19b4800 f0948130 > f095c03c 00021170 c0341640 c0341640 ef724c10 00000000 00000000 00000000 > f0b5b000 00000000 00000001 f090e52d 00021170 00000000 00000ce4 00000ce4 > Call Trace: [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] > 0xe0c (0xe80d7c14) > [] osi_UFSOpen [libafs-2.4.22-1.2174.nptl-i686] 0x120 (0xe80d7c30) > [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] 0xe0c (0xe80d7c34) > [] afs_InitCacheFile [libafs-2.4.22-1.2174.nptl-i686] 0x10d (0xe80d7c60) > [] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c7c) > [] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c80) > [] afs_InitVolumeInfo [libafs-2.4.22-1.2174.nptl-i686] 0x5b (0xe80d7c90) > [] afs_syscall_call [libafs-2.4.22-1.2174.nptl-i686] 0x5ce (0xe80d7cb0) > [] activate_page [kernel] 0xab (0xe80d7ce4) > [] getblk [kernel] 0x59 (0xe80d7d00) > [] bread [kernel] 0x20 (0xe80d7d24) > [] is_tree_node [reiserfs] 0x74 (0xe80d7d40) > [] search_by_key [reiserfs] 0x5b1 (0xe80d7d54) > [] journal_end [reiserfs] 0x27 (0xe80d7d94) > [] reiserfs_dirty_inode [reiserfs] 0x7e (0xe80d7da8) > [] search_by_entry_key [reiserfs] 0xc8 (0xe80d7dd4) > [] pathrelse [reiserfs] 0x21 (0xe80d7df4) > [] reiserfs_readdir [reiserfs] 0x3c7 (0xe80d7e04) > [] __alloc_pages [kernel] 0x64 (0xe80d7e44) > [] __alloc_pages [kernel] 0x64 (0xe80d7e68) > [] vm_enough_memory [kernel] 0x33 (0xe80d7e84) > [] rb_insert_color [kernel] 0x8f (0xe80d7ea0) > [] do_wp_page [kernel] 0x4d (0xe80d7ebc) > [] handle_mm_fault [kernel] 0xf9 (0xe80d7ee0) > [] do_page_fault [kernel] 0x138 (0xe80d7f0c) > [] afs_syscall [libafs-2.4.22-1.2174.nptl-i686] 0x190 (0xe80d7f40) > [] do_page_fault [kernel] 0x0 (0xe80d7fb0) > [] system_call [kernel] 0x33 (0xe80d7fc0) > > > Code: c6 05 ff ff ff ff 2a 83 c4 1c c3 90 8d 74 26 00 b8 1e bd 95 > > with kernel 2.4.22-2166 and is the same version OpenAFS working good and > startup client AFS good. > > Helpme please. > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From shadow@dementia.org Wed Mar 3 22:35:39 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 3 Mar 2004 17:35:39 -0500 (EST) Subject: [OpenAFS] start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040303223230.M17878@soltis.cc> References: <20040303223230.M17878@soltis.cc> Message-ID: On Wed, 3 Mar 2004, jds wrote: > Hi: Iam compile OpenAFS 1.2.11-fc1 with kernel 2.4.22-1.2174.nptl is OK > > the problems is when start the client AFS recive the messages: so put the cache on ext2 and not whatever weird filesystem you have, i bet > > [root@angelinux modload]# service afs start > Found libafs-2.4.22-1.2174.nptl-i686.o from SymTable... Loading... > Starting AFS services..... > /etc/init.d/afs: line 305: 3300 Segmentation fault /usr/vice/etc/afsd > ${AFSD_OPTIONS} > [root@angelinux modload]# lsmod > Module Size Used by Tainted: PF > libafs-2.4.22-1.2174.nptl-i686 483360 0 (unused) > parport_pc 18756 1 (autoclean) > etc,etc > > In log messages: > Starting AFS cache scan...Can't open inode 135536 > Unable to handle kernel paging request at virtual address ffffffff > printing eip: > f093e1b0 > *pde = 00002067 > *pte = 00000000 > Oops: 0002 > libafs-2.4.22-1.2174.nptl-i686 parport_pc lp parport autofs tg3 floppy sg > keybdev hid ehci-hcd usb-uhci usbcore mousedev input i830 agpgart reiserfs > ata_piix > CPU: 0 > EIP: 0060:[] Tainted: PF > EFLAGS: 00010282 > > EIP is at osi_Panic [libafs-2.4.22-1.2174.nptl-i686] 0x20 (2.4.22-1.2174.nptl) > eax: 00000018 ebx: e7bd2580 ecx: 00000001 edx: e80d6000 > esi: ea666b80 edi: ea666c08 ebp: 00000400 esp: e80d7c14 > ds: 0068 es: 0068 ss: 0068 > Process afsd (pid: 3300, stackpage=e80d7000) > Stack: f095c03c 00021170 c0341640 c0341640 ea666b80 ea666c08 c19b4800 f0948130 > f095c03c 00021170 c0341640 c0341640 ef724c10 00000000 00000000 00000000 > f0b5b000 00000000 00000001 f090e52d 00021170 00000000 00000ce4 00000ce4 > Call Trace: [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] > 0xe0c (0xe80d7c14) > [] osi_UFSOpen [libafs-2.4.22-1.2174.nptl-i686] 0x120 (0xe80d7c30) > [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] 0xe0c (0xe80d7c34) > [] afs_InitCacheFile [libafs-2.4.22-1.2174.nptl-i686] 0x10d (0xe80d7c60) > [] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c7c) > [] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c80) > [] afs_InitVolumeInfo [libafs-2.4.22-1.2174.nptl-i686] 0x5b (0xe80d7c90) > [] afs_syscall_call [libafs-2.4.22-1.2174.nptl-i686] 0x5ce (0xe80d7cb0) > [] activate_page [kernel] 0xab (0xe80d7ce4) > [] getblk [kernel] 0x59 (0xe80d7d00) > [] bread [kernel] 0x20 (0xe80d7d24) > [] is_tree_node [reiserfs] 0x74 (0xe80d7d40) > [] search_by_key [reiserfs] 0x5b1 (0xe80d7d54) > [] journal_end [reiserfs] 0x27 (0xe80d7d94) > [] reiserfs_dirty_inode [reiserfs] 0x7e (0xe80d7da8) > [] search_by_entry_key [reiserfs] 0xc8 (0xe80d7dd4) > [] pathrelse [reiserfs] 0x21 (0xe80d7df4) > [] reiserfs_readdir [reiserfs] 0x3c7 (0xe80d7e04) > [] __alloc_pages [kernel] 0x64 (0xe80d7e44) > [] __alloc_pages [kernel] 0x64 (0xe80d7e68) > [] vm_enough_memory [kernel] 0x33 (0xe80d7e84) > [] rb_insert_color [kernel] 0x8f (0xe80d7ea0) > [] do_wp_page [kernel] 0x4d (0xe80d7ebc) > [] handle_mm_fault [kernel] 0xf9 (0xe80d7ee0) > [] do_page_fault [kernel] 0x138 (0xe80d7f0c) > [] afs_syscall [libafs-2.4.22-1.2174.nptl-i686] 0x190 (0xe80d7f40) > [] do_page_fault [kernel] 0x0 (0xe80d7fb0) > [] system_call [kernel] 0x33 (0xe80d7fc0) > > > Code: c6 05 ff ff ff ff 2a 83 c4 1c c3 90 8d 74 26 00 b8 1e bd 95 > > with kernel 2.4.22-2166 and is the same version OpenAFS working good and > startup client AFS good. > > Helpme please. > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From astanley@strozllc.com Wed Mar 3 23:01:29 2004 From: astanley@strozllc.com (Aaron Stanley) Date: Wed, 03 Mar 2004 18:01:29 -0500 Subject: [OpenAFS] Tool to troubleshoot Vos Release failure Message-ID: Hi All, So I have a stubborn volume that refuses to release. It's on a server that has a high latency (>100ms) connection, but has the same bandwidth as my other servers (T1). I am wondering what tools I can use to figure out why the release is failing (unless I simply will never be able to a release a volume on that slow of a link? I hope not!). Has anybody written anything that can help me here? Are there any settings I can change on my vlservers that will get around the latency? Thanks in advance. - AB -- Aaron Stanley Director, Information Technology Stroz Friedberg, LLC 15 Maiden Lane, Suite 1208 New York, NY 10038 212/981.6534[o] | 917/859.1503[c] | 212/981.6545[f] *********************************************************************** This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No right to confidential or privileged treatment of this message is waived or lost by any error in transmission. If you have received this message in error, please immediately notify the sender by e-mail or by telephone at 212 981 6540, delete the message and all copies from your system and destroy any hard copies. You must not, directly or indirectly, use, disclose, distribute, print or copy any part of this message if you are not the intended recipient. ************************************************************************ From jds@soltis.cc Wed Mar 3 23:53:00 2004 From: jds@soltis.cc (jds) Date: Wed, 3 Mar 2004 17:53:00 -0600 Subject: [OpenAFS] start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: References: <20040303223230.M17878@soltis.cc> Message-ID: <20040303234028.M27109@soltis.cc> Hi Derek: Thanks by comments, both my next question is? why working good client openafs with kernel 2.4.22-1-xxx before the 2.4.22-1-2174? No problems with cache, Iam use all filesystem type reiserfs y startup client afs OK. Any idea Regards. ---------- Original Message ----------- From: Derek Atkins To: "jds" Cc: OpenAFS-info@openafs.org Sent: Wed, 03 Mar 2004 17:33:38 -0500 Subject: Re: [OpenAFS] start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl > What kind of filesystem is /usr/vice/cache? It looks like it might > be reiserfs. If so, that's your problem: you cannot put an AFS Cache > on reiserfs. Change the file type to ext{2,3}. > > -derek > > "jds" writes: > > > Hi: Iam compile OpenAFS 1.2.11-fc1 with kernel 2.4.22-1.2174.nptl is OK > > > > the problems is when start the client AFS recive the messages: > > > > > > [root@angelinux modload]# service afs start > > Found libafs-2.4.22-1.2174.nptl-i686.o from SymTable... Loading... > > Starting AFS services..... > > /etc/init.d/afs: line 305: 3300 Segmentation fault /usr/vice/etc/afsd > > ${AFSD_OPTIONS} > > [root@angelinux modload]# lsmod > > Module Size Used by Tainted: PF > > libafs-2.4.22-1.2174.nptl-i686 483360 0 (unused) > > parport_pc 18756 1 (autoclean) > > etc,etc > > > > In log messages: > > Starting AFS cache scan...Can't open inode 135536 > > Unable to handle kernel paging request at virtual address ffffffff > > printing eip: > > f093e1b0 > > *pde = 00002067 > > *pte = 00000000 > > Oops: 0002 > > libafs-2.4.22-1.2174.nptl-i686 parport_pc lp parport autofs tg3 floppy sg > > keybdev hid ehci-hcd usb-uhci usbcore mousedev input i830 agpgart reiserfs > > ata_piix > > CPU: 0 > > EIP: 0060:[] Tainted: PF > > EFLAGS: 00010282 > > > > EIP is at osi_Panic [libafs-2.4.22-1.2174.nptl-i686] 0x20 (2.4.22-1.2174.nptl) > > eax: 00000018 ebx: e7bd2580 ecx: 00000001 edx: e80d6000 > > esi: ea666b80 edi: ea666c08 ebp: 00000400 esp: e80d7c14 > > ds: 0068 es: 0068 ss: 0068 > > Process afsd (pid: 3300, stackpage=e80d7000) > > Stack: f095c03c 00021170 c0341640 c0341640 ea666b80 ea666c08 c19b4800 f0948130 > > f095c03c 00021170 c0341640 c0341640 ef724c10 00000000 00000000 00000000 > > f0b5b000 00000000 00000001 f090e52d 00021170 00000000 00000ce4 00000ce4 > > Call Trace: [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] > > 0xe0c (0xe80d7c14) > > [] osi_UFSOpen [libafs-2.4.22-1.2174.nptl-i686] 0x120 (0xe80d7c30) > > [] .rodata.str1.1 [libafs-2.4.22-1.2174.nptl-i686] 0xe0c (0xe80d7c34) > > [] afs_InitCacheFile [libafs-2.4.22-1.2174.nptl-i686] 0x10d (0xe80d7c60) > > [] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c7c) > > [] reiserfs_file_operations [reiserfs] 0x0 (0xe80d7c80) > > [] afs_InitVolumeInfo [libafs-2.4.22-1.2174.nptl-i686] 0x5b (0xe80d7c90) > > [] afs_syscall_call [libafs-2.4.22-1.2174.nptl-i686] 0x5ce (0xe80d7cb0) > > [] activate_page [kernel] 0xab (0xe80d7ce4) > > [] getblk [kernel] 0x59 (0xe80d7d00) > > [] bread [kernel] 0x20 (0xe80d7d24) > > [] is_tree_node [reiserfs] 0x74 (0xe80d7d40) > > [] search_by_key [reiserfs] 0x5b1 (0xe80d7d54) > > [] journal_end [reiserfs] 0x27 (0xe80d7d94) > > [] reiserfs_dirty_inode [reiserfs] 0x7e (0xe80d7da8) > > [] search_by_entry_key [reiserfs] 0xc8 (0xe80d7dd4) > > [] pathrelse [reiserfs] 0x21 (0xe80d7df4) > > [] reiserfs_readdir [reiserfs] 0x3c7 (0xe80d7e04) > > [] __alloc_pages [kernel] 0x64 (0xe80d7e44) > > [] __alloc_pages [kernel] 0x64 (0xe80d7e68) > > [] vm_enough_memory [kernel] 0x33 (0xe80d7e84) > > [] rb_insert_color [kernel] 0x8f (0xe80d7ea0) > > [] do_wp_page [kernel] 0x4d (0xe80d7ebc) > > [] handle_mm_fault [kernel] 0xf9 (0xe80d7ee0) > > [] do_page_fault [kernel] 0x138 (0xe80d7f0c) > > [] afs_syscall [libafs-2.4.22-1.2174.nptl-i686] 0x190 (0xe80d7f40) > > [] do_page_fault [kernel] 0x0 (0xe80d7fb0) > > [] system_call [kernel] 0x33 (0xe80d7fc0) > > > > > > Code: c6 05 ff ff ff ff 2a 83 c4 1c c3 90 8d 74 26 00 b8 1e bd 95 > > > > with kernel 2.4.22-2166 and is the same version OpenAFS working good and > > startup client AFS good. > > > > Helpme please. > > > > _______________________________________________ > > OpenAFS-info mailing list > > OpenAFS-info@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-info > > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available ------- End of Original Message ------- From shadow@dementia.org Wed Mar 3 23:17:42 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 3 Mar 2004 18:17:42 -0500 (EST) Subject: [OpenAFS] start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040303234028.M27109@soltis.cc> References: <20040303223230.M17878@soltis.cc> <20040303234028.M27109@soltis.cc> Message-ID: On Wed, 3 Mar 2004, jds wrote: > Hi Derek: > > Thanks by comments, both my next question is? why working good client > openafs with kernel 2.4.22-1-xxx before the 2.4.22-1-2174? > > No problems with cache, Iam use all filesystem type reiserfs y startup > client afs OK. other than the oops, which is a cache on reiser problem. stop using reiser for your cache. there's no point in arguing about it, just try what was suggested, you will get no other suggestions, because it's not worth our time to come up with suggestions that aren't going to fix your problem, and it's hopefully not worth your time to try them. i mean, if you want other suggestions, i'll get my non-techie wife to come up with some when she reappears, but if you want to solve the problem, put the cache on ext2 From pete@deek.org Wed Mar 3 23:27:50 2004 From: pete@deek.org (Pete Walters) Date: Wed, 3 Mar 2004 17:27:50 -0600 Subject: [OpenAFS] start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: References: <20040303223230.M17878@soltis.cc> <20040303234028.M27109@soltis.cc> Message-ID: <20040303232750.GA28688@marvin.deek.org> On 2004-03-03 18:17, Derrick J Brashear wrote: > On Wed, 3 Mar 2004, jds wrote: > > > Hi Derek: > > > > Thanks by comments, both my next question is? why working good client > > openafs with kernel 2.4.22-1-xxx before the 2.4.22-1-2174? > > > > No problems with cache, Iam use all filesystem type reiserfs y startup > > client afs OK. > > other than the oops, which is a cache on reiser problem. stop using reiser > for your cache. there's no point in arguing about it, just try what was > suggested, you will get no other suggestions, because it's not worth our > time to come up with suggestions that aren't going to fix your problem, > and it's hopefully not worth your time to try them. > > i mean, if you want other suggestions, i'll get my non-techie wife to come > up with some when she reappears, but if you want to solve the problem, put > the cache on ext2 > > > > > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From jds@soltis.cc Thu Mar 4 01:48:58 2004 From: jds@soltis.cc (jds) Date: Wed, 3 Mar 2004 19:48:58 -0600 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304002804.GA5722@dbz.icequake.net> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> Message-ID: <20040304014303.M64769@soltis.cc> Hi Ryan: Thanks for your help, the client openafs working again. loop: loaded (max 8 devices) Journalled Block Device driver loaded kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal EXT3-fs: mounted filesystem with ordered data mode. Found sys_call_table at c033d9f0 Starting AFS cache scan...found 0 non-empty cache files (0%). [root@angelinux root]# df -T Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/hda2 reiserfs 12947988 2838624 10109364 22% / /dev/hda3 reiserfs 10241116 33320 10207796 1% /home none tmpfs 382776 0 382776 0% /dev/shm /var/afscache ext3 92659 4722 83153 6% /usr/vice/cache AFS afs 9000000 0 9000000 0% /afs Regards. Thanks at all people for help me ( Derek, Pete, Derrick ) ---------- Original Message ----------- From: Ryan Underwood To: reiserfs-list@namesys.com Sent: Wed, 3 Mar 2004 18:28:04 -0600 Subject: Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl > On Wed, Mar 03, 2004 at 07:00:06PM -0600, jds wrote: > > Hi: Iam compile OpenAFS 1.2.11-fc1 with kernel 2.4.22-1.2174.nptl is OK > > > > problems with reiserfs 3.6 and Fedora Core 1 > > the problems is when start the client AFS recive the messages: > > > > [root@angelinux modload]# service afs start > > Found libafs-2.4.22-1.2174.nptl-i686.o from SymTable... Loading... > > Starting AFS services..... > > /etc/init.d/afs: line 305: 3300 Segmentation fault /usr/vice/etc/afsd > > ${AFSD_OPTIONS} > > You can't use the OpenAFS client on a ReiserFS filesystem. It currently > only supports ext2/ext3 filesystems. If you only have reiser > filesystems, just make a big empty file: > # dd if=/dev/zero of=/var/afscache > and make an ext2 filesystem on it: > # mke2fs -F /var/afscache > and loop-mount it wherever your afs cache needs to be. > # mount -o loop,rw /var/afscache /usr/vice/cache > > You can automate this in your fstab: > /var/afscache /usr/vice/cache ext2 defaults,loop 0 0 > > -- > Ryan Underwood, ------- End of Original Message ------- From nemesis-lists@icequake.net Thu Mar 4 07:18:46 2004 From: nemesis-lists@icequake.net (Ryan Underwood) Date: Thu, 4 Mar 2004 01:18:46 -0600 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <4046A6A8.2000609@matchmail.com> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> Message-ID: <20040304071846.GB324@dbz.icequake.net> --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 03, 2004 at 07:46:48PM -0800, Mike Fedyk wrote: > jds wrote: > >Hi Ryan: > > > > Thanks for your help, the client openafs working again. > > > >loop: loaded (max 8 devices) > >Journalled Block Device driver loaded > >kjournald starting. Commit interval 5 seconds > >EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal > >EXT3-fs: mounted filesystem with ordered data mode. >=20 > No, if you're going to be stacking filesystems, use ext2, not ext3. You= =20 > will get better performance, and there's no use in having two levels of= =20 > journaling in this case. You might also think about bigger than 100MB cache file. A big cache helps out AFS client performance tremendously. But definitely use ext2 and not ext3 as others have said. --=20 Ryan Underwood, --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFARthWIonHnh+67jkRAs00AJ47zXHzxuU1PGEA00jfABvlrZzhhACfaTyz DYTjd3+VHSf8k+AkjcIMz/8= =MYcl -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From shadow@dementia.org Thu Mar 4 07:24:04 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 4 Mar 2004 02:24:04 -0500 (EST) Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304071846.GB324@dbz.icequake.net> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> Message-ID: Removed 50 gazillion things including the reiserfs list from the CCs on this; They don't have persistent inode numbers, and they feel they don't need them, most applications don't care, the afs cache does, and that's fine. There's no need to involve them. I don't know who added them, and I'm not pointing fingers. I just figured I'd tell you the why. On Thu, 4 Mar 2004, Ryan Underwood wrote: > > >EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal > > >EXT3-fs: mounted filesystem with ordered data mode. > > > > No, if you're going to be stacking filesystems, use ext2, not ext3. You > > will get better performance, and there's no use in having two levels of > > journaling in this case. > > You might also think about bigger than 100MB cache file. A big cache > helps out AFS client performance tremendously. But definitely use ext2 > and not ext3 as others have said. Indeed, and yes, if you're going to make any decent amount of client use, seriously consider devoting more than 100mb to the cache. You'll be happier with performance if you're not turning it over as often; If you make it too small you're throwing away one benefit of AFS. From Todd_Lewis@unc.edu Thu Mar 4 13:55:37 2004 From: Todd_Lewis@unc.edu (Todd M. Lewis) Date: Thu, 04 Mar 2004 08:55:37 -0500 Subject: [OpenAFS] start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: References: <20040303223230.M17878@soltis.cc> <20040303234028.M27109@soltis.cc> Message-ID: <40473559.9070809@email.unc.edu> This is a multi-part message in MIME format. --------------080505040402060107050106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Derrick J Brashear wrote: > On Wed, 3 Mar 2004, jds wrote: > > >>Hi Derek: >> >> Thanks by comments, both my next question is? why working good client >>openafs with kernel 2.4.22-1-xxx before the 2.4.22-1-2174? >> >> No problems with cache, Iam use all filesystem type reiserfs y startup >>client afs OK. > > > other than the oops, which is a cache on reiser problem. stop using reiser > for your cache. Would a patch (see attached) for src/afsd/afs.rc.linux be out of line? Seems noobies are going to hit their collective head on this forever, and we'll keep answering this question just as badly... -- +--------------------------------------------------------------+ / Todd_Lewis@unc.edu 919-962-5273 http://www.unc.edu/~utoddl / / I fired my masseuse today. She just rubbed me the wrong way. / +--------------------------------------------------------------+ --------------080505040402060107050106 Content-Type: text/plain; name="afs.rc.linux-ext23.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="afs.rc.linux-ext23.patch" --- afs.rc.linux-orig 2004-03-04 08:28:23.000000000 -0500 +++ afs.rc.linux 2004-03-04 08:47:24.000000000 -0500 @@ -177,6 +177,12 @@ exit 1 fi + cachefs=$(grep $(df $CACHE | grep $CACHE | cut -f1 -d' ') /etc/mtab | cut -f3 -d' ') + if [ "${cachefs:-none}" != "ext2" ] && [ "${cachefs:-none}" != "ext3" ] ; then + echo $CACHE is not an ext2 or ext3 filesystem. Not starting AFS. + exit 1 + fi + # use the prefix command if required set_prefix /sbin/insmod ${PREFIX:+-P $PREFIX} -f -m $MODLOADDIR/$LIBAFS > $MODLOADDIR/libafs.map 2>&1 --------------080505040402060107050106-- From pete@deek.org Thu Mar 4 15:13:49 2004 From: pete@deek.org (Pete Walters) Date: Thu, 4 Mar 2004 09:13:49 -0600 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304071846.GB324@dbz.icequake.net> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> Message-ID: <20040304151349.GA30594@marvin.deek.org> Are there known problems with having your cache on an ext3 partition instead of ext2? On 2004-03-04 01:18, Ryan Underwood wrote: > On Wed, Mar 03, 2004 at 07:46:48PM -0800, Mike Fedyk wrote: > > jds wrote: > > >Hi Ryan: > > > > > > Thanks for your help, the client openafs working again. > > > > > >loop: loaded (max 8 devices) > > >Journalled Block Device driver loaded > > >kjournald starting. Commit interval 5 seconds > > >EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal > > >EXT3-fs: mounted filesystem with ordered data mode. > > > > No, if you're going to be stacking filesystems, use ext2, not ext3. You > > will get better performance, and there's no use in having two levels of > > journaling in this case. > > You might also think about bigger than 100MB cache file. A big cache > helps out AFS client performance tremendously. But definitely use ext2 > and not ext3 as others have said. > > -- > Ryan Underwood, From shadow@dementia.org Thu Mar 4 15:25:26 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 4 Mar 2004 10:25:26 -0500 (EST) Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304151349.GA30594@marvin.deek.org> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> <20040304151349.GA30594@marvin.deek.org> Message-ID: On Thu, 4 Mar 2004, Pete Walters wrote: > Are there known problems with having your cache on an ext3 partition > instead of ext2? Until the machine on my lap magically changed into a Mac, I'd been running an ext3 cache. Let me put it another way. No bug I've had to track or fix could be attributed to ext3, proven or unproven. From hendrik.hoeth@cern.ch Thu Mar 4 15:56:05 2004 From: hendrik.hoeth@cern.ch (Hendrik Hoeth) Date: Thu, 4 Mar 2004 16:56:05 +0100 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304151349.GA30594@marvin.deek.org> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> <20040304151349.GA30594@marvin.deek.org> Message-ID: <20040304155605.GD13435@mail.physik.uni-wuppertal.de> Thus spake Pete Walters (pete@deek.org): > Are there known problems with having your cache on an ext3 partition > instead of ext2? I'm using ext3 for months without a single problem. -- You only realize how much you love something if you have to live without it: http://wwwasd.web.cern.ch/wwwasd/paw/ From deej@thayer.dartmouth.edu Thu Mar 4 16:00:12 2004 From: deej@thayer.dartmouth.edu (Dj Merrill) Date: Thu, 04 Mar 2004 11:00:12 -0500 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304155605.GD13435@mail.physik.uni-wuppertal.de> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> <20040304151349.GA30594@marvin.deek.org> <20040304155605.GD13435@mail.physik.uni-wuppertal.de> Message-ID: <4047528C.8050705@thayer.dartmouth.edu> Hendrik Hoeth wrote: > Thus spake Pete Walters (pete@deek.org): > > >>Are there known problems with having your cache on an ext3 partition >>instead of ext2? > > > I'm using ext3 for months without a single problem. > Ditto. -Dj -- Dj Merrill Thayer School of Engineering ThUG Sr. Unix Systems Administrator 8000 Cummings Hall deej@thayer.dartmouth.edu - N1JOV Dartmouth College, Hanover, NH 03755 "On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows 95 or better'. So I installed Linux." -Anonymous From dwb7@ccmr.cornell.edu Thu Mar 4 18:09:18 2004 From: dwb7@ccmr.cornell.edu (David Botsch) Date: Thu, 4 Mar 2004 13:09:18 -0500 Subject: [OpenAFS] AuthServer/Admin and cell name change Message-ID: <20040304180918.GE23688@domino.ccmr.cornell.edu> In the process of changing an afs cell name, does anything need to be done with the AuthServer/Admin@CELL principal? Presumably, it wouldn't be accessible anymore as its password salted with the old cell name wouldn't work anymore. Change to a new random pw? Delete the principal? Do nothing? Thanks! -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7@ccmr.cornell.edu ******************************** From tcreedon@easystreet.com Thu Mar 4 18:22:46 2004 From: tcreedon@easystreet.com (ted creedon) Date: Thu, 4 Mar 2004 10:22:46 -0800 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <4047528C.8050705@thayer.dartmouth.edu> Message-ID: <20040304182246.68F54B0A1@smtpauth.easystreet.com> Ditto, ext3 works fine on SuSE 9.0 boxes, 250 Gig. Correct me if I'm wrong but ext2 runs fsck which takes a long time on large partitions, ext3 is fairly quick on boot up/down. Tedc -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Dj Merrill Sent: Thursday, March 04, 2004 8:00 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl Hendrik Hoeth wrote: > Thus spake Pete Walters (pete@deek.org): > > >>Are there known problems with having your cache on an ext3 partition >>instead of ext2? > > > I'm using ext3 for months without a single problem. > Ditto. -Dj -- Dj Merrill Thayer School of Engineering ThUG Sr. Unix Systems Administrator 8000 Cummings Hall deej@thayer.dartmouth.edu - N1JOV Dartmouth College, Hanover, NH 03755 "On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows 95 or better'. So I installed Linux." -Anonymous _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From shadow@dementia.org Thu Mar 4 18:33:02 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 4 Mar 2004 13:33:02 -0500 (EST) Subject: [OpenAFS] AuthServer/Admin and cell name change In-Reply-To: <20040304180918.GE23688@domino.ccmr.cornell.edu> References: <20040304180918.GE23688@domino.ccmr.cornell.edu> Message-ID: On Thu, 4 Mar 2004, David Botsch wrote: > In the process of changing an afs cell name, does anything need to be > done with the AuthServer/Admin@CELL principal? Presumably, it wouldn't > be accessible anymore as its password salted with the old cell name > wouldn't work anymore. so why do you even know its password? it's a "key", it need not have ever been a password, generally. > Change to a new random pw? > Delete the principal? > Do nothing? > > Thanks! > > -- > ******************************** > David William Botsch > Consultant/Advisor II > CCMR Computing Facility > dwb7@ccmr.cornell.edu > ******************************** > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From dwb7@ccmr.cornell.edu Thu Mar 4 19:00:09 2004 From: dwb7@ccmr.cornell.edu (David Botsch) Date: Thu, 4 Mar 2004 14:00:09 -0500 Subject: [OpenAFS] AuthServer/Admin and cell name change In-Reply-To: ; from shadow@dementia.org on Thu, Mar 04, 2004 at 13:33:02 -0500 References: <20040304180918.GE23688@domino.ccmr.cornell.edu> Message-ID: <20040304190009.GG23688@domino.ccmr.cornell.edu> I don't know what it's password is (tho, interestingly enough, it shows a last change date of yesterday). So, does the kas server just automatically set a password every time it comes up (meaning I don't need to do anything with this principal)? thanks! On 2004.03.04 13:33 Derrick J Brashear wrote: > On Thu, 4 Mar 2004, David Botsch wrote: > > > In the process of changing an afs cell name, does anything need to > be > > done with the AuthServer/Admin@CELL principal? Presumably, it > wouldn't > > be accessible anymore as its password salted with the old cell name > > wouldn't work anymore. > > so why do you even know its password? it's a "key", it need not have > ever > been a password, generally. > > > Change to a new random pw? > > Delete the principal? > > Do nothing? > > > > Thanks! > > > > -- > > ******************************** > > David William Botsch > > Consultant/Advisor II > > CCMR Computing Facility > > dwb7@ccmr.cornell.edu > > ******************************** > > _______________________________________________ > > 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 > -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7@ccmr.cornell.edu ******************************** From lwc@vapid.ath.cx Thu Mar 4 19:11:14 2004 From: lwc@vapid.ath.cx (Larry W. Cashdollar) Date: Thu, 4 Mar 2004 14:11:14 -0500 (EST) Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304151349.GA30594@marvin.deek.org> Message-ID: <20040304141048.W4175-100000@vapid.ath.cx> On Thu, 4 Mar 2004, Pete Walters wrote: > Are there known problems with having your cache on an ext3 partition > instead of ext2? I have been running on ext3 for months with out any issues. - Larry C$ From shadow@dementia.org Thu Mar 4 19:22:33 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 4 Mar 2004 14:22:33 -0500 (EST) Subject: [OpenAFS] AuthServer/Admin and cell name change In-Reply-To: <20040304190009.GG23688@domino.ccmr.cornell.edu> References: <20040304180918.GE23688@domino.ccmr.cornell.edu> <20040304190009.GG23688@domino.ccmr.cornell.edu> Message-ID: On Thu, 4 Mar 2004, David Botsch wrote: > I don't know what it's password is (tho, interestingly enough, it shows > a last change date of yesterday). So, does the kas server just > automatically set a password every time it comes up (meaning I don't > need to do anything with this principal)? it autochanges every N transactions, or maybe N days. i don't remember. From danno@internet2.edu Thu Mar 4 23:07:25 2004 From: danno@internet2.edu (Dan Pritts) Date: Thu, 4 Mar 2004 18:07:25 -0500 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304071846.GB324@dbz.icequake.net> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> Message-ID: <20040304230725.GA19887@internet2.edu> On Thu, Mar 04, 2004 at 01:18:46AM -0600, Ryan Underwood wrote: > > No, if you're going to be stacking filesystems, use ext2, not ext3. You > > will get better performance, and there's no use in having two levels of > > journaling in this case. > > You might also think about bigger than 100MB cache file. A big cache > helps out AFS client performance tremendously. But definitely use ext2 > and not ext3 as others have said. I realize it won't work out of the box, but has anyone given any thought to putting the cache in tmpfs? Seems like this might be the best of both worlds - when the system is low on RAM it can use swap, but when you've got plenty of RAM you avoid the overhead of writing the cache files to disk. more flexible than memcache, faster than disk cache. My understanding (limited) of the tmpfs on linux suggests that it might be an easy change to make in the code for someone who understood the data structions better than i do ;) mostly, just curious...can anyone say? danno -- dan pritts danno@internet2.edu systems administrator 734/352-4953 office internet2 734/834-7224 mobile From shadow@dementia.org Thu Mar 4 23:17:42 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 4 Mar 2004 18:17:42 -0500 (EST) Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304230725.GA19887@internet2.edu> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> <20040304230725.GA19887@internet2.edu> Message-ID: Pruned the CC list again. Why are people still copying the reiserfs list? Edit your headers. On Thu, 4 Mar 2004, Dan Pritts wrote: > I realize it won't work out of the box, but has anyone given any > thought to putting the cache in tmpfs? I've given it thought. > Seems like this might be the best of both worlds - when the system is low > on RAM it can use swap, but when you've got plenty of RAM you avoid the > overhead of writing the cache files to disk. > > more flexible than memcache, faster than disk cache. My understanding > (limited) of the tmpfs on linux suggests that it might be an easy change > to make in the code for someone who understood the data structions better > than i do ;) Not that easy. Same issue as the cache has with reiser, IIRC. look in the archives about 2 years ago. From tcreedon@easystreet.com Fri Mar 5 00:40:46 2004 From: tcreedon@easystreet.com (ted creedon) Date: Thu, 4 Mar 2004 16:40:46 -0800 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: Message-ID: <20040305004047.19FB6B096@smtpauth.easystreet.com> Or a memory mapped file? Tedc -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Derrick J Brashear Sent: Thursday, March 04, 2004 3:18 PM To: openafs-info@openafs.org Subject: Re: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl Pruned the CC list again. Why are people still copying the reiserfs list? Edit your headers. On Thu, 4 Mar 2004, Dan Pritts wrote: > I realize it won't work out of the box, but has anyone given any > thought to putting the cache in tmpfs? I've given it thought. > Seems like this might be the best of both worlds - when the system is low > on RAM it can use swap, but when you've got plenty of RAM you avoid the > overhead of writing the cache files to disk. > > more flexible than memcache, faster than disk cache. My understanding > (limited) of the tmpfs on linux suggests that it might be an easy change > to make in the code for someone who understood the data structions better > than i do ;) Not that easy. Same issue as the cache has with reiser, IIRC. look in the archives about 2 years ago. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From nemesis-lists@icequake.net Fri Mar 5 01:40:44 2004 From: nemesis-lists@icequake.net (Ryan Underwood) Date: Thu, 4 Mar 2004 19:40:44 -0600 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304230725.GA19887@internet2.edu> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> <20040304230725.GA19887@internet2.edu> Message-ID: <20040305014044.GA27737@dbz.icequake.net> --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 04, 2004 at 06:07:25PM -0500, Dan Pritts wrote: > >=20 > > You might also think about bigger than 100MB cache file. A big cache > > helps out AFS client performance tremendously. But definitely use ext2 > > and not ext3 as others have said. >=20 > I realize it won't work out of the box, but has anyone given any > thought to putting the cache in tmpfs? >=20 > Seems like this might be the best of both worlds - when the system is low > on RAM it can use swap, but when you've got plenty of RAM you avoid the > overhead of writing the cache files to disk. I thought about it, and indeed it would be beneficial when running a server with no writeable medium. But there was some discussion on the OpenAFS list a while back, and it would take some work to make the cache manager work with tmpfs. Basically it's the same problem with tmpfs as with reiser, xfs, etc as a cache; the cache manager was developer rather closely coupled to ext2, and other filesystems just don't support the operations that the cache manager currently needs. I'm not sure if there are any plans to fix that at the moment, perhaps bigger fish to fry, such as getting some real AFS functionality going for 2.6 users. For 2.6, we need a per-process credentials API as well as a way for the OpenAFS module to install its hooks. I haven't seen=20 anything happening recently except for the very feature-limited kAFS client (no authentication, no cache, etc). --=20 Ryan Underwood, --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAR9qbIonHnh+67jkRAkgoAKCvR9CWk6gNoVETOcJmczT+yOkLRgCglgNr XGAHk80a1jWYfQmFNf/SIWY= =8FwQ -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From shadow@dementia.org Fri Mar 5 02:06:00 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 4 Mar 2004 21:06:00 -0500 (EST) Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040305014044.GA27737@dbz.icequake.net> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> <20040304230725.GA19887@internet2.edu> <20040305014044.GA27737@dbz.icequake.net> Message-ID: *Again* editing the CC line. Come on people, get with the program. On Thu, 4 Mar 2004, Ryan Underwood wrote: > OpenAFS list a while back, and it would take some work to make the cache > manager work with tmpfs. Basically it's the same problem with tmpfs as > with reiser, xfs, etc as a cache; the cache manager was developer rather > closely coupled to ext2, and other filesystems just don't support the > operations that the cache manager currently needs. No, the cache manager was developed for BSD ffs, before there was such a thing as ext2, or even Linux. It just so happens that ext2/ext3 are close enough to that in terms of feature set that they can be easily supported. From tcreedon@easystreet.com Fri Mar 5 17:45:41 2004 From: tcreedon@easystreet.com (ted creedon) Date: Fri, 5 Mar 2004 09:45:41 -0800 Subject: [OpenAFS] Linux 2.6 In-Reply-To: Message-ID: <20040305174541.CE6E0294CB@smtpauth.easystreet.com> Can someone send me a list of what needs to be done to support AFS in 2.6? Tedc From m.raitza@gmx.net Fri Mar 5 18:44:48 2004 From: m.raitza@gmx.net (Michael Raitza) Date: Fri, 5 Mar 2004 19:44:48 +0100 Subject: [OpenAFS] Server freezes Message-ID: <20040305184448.GA5425@fractal.locke.home> Hi, I've got a similar problem. I get the "unable to handle kernel paging request at address...." errors too, under certain circumstances that, I found out, are reproduceable. The crashing service is NOT always the same, e.g. the "kswapd". I'm using a patched 2.4.22 linux kernel and openafs 1.2.10. I am NOT using another than an ext2 partition for the cache. The error first occured as I transfered several Gigs of files, not volumes, from one volume to another using the AFS Client installed on the server. At about 2GiB, I got the error, and the server refused to work completely, no clean shutdown possible. First I thought it was a bug in the Cache Manager, so I enlarged the cache partition, error at about 2GiB. Then I regularly stopped the copy process and cleaned the cache, that worked. Later I copied another several Gigs of Data, but from a remote client. I got the error at about 2 or 3 GiB. So I think the error seems to be at the server side, isn't it? regards, Michael Raitza From dhk@ccre.com Sat Mar 6 01:23:35 2004 From: dhk@ccre.com (Kim (Dexter) Kimball) Date: Fri, 5 Mar 2004 18:23:35 -0700 Subject: [OpenAFS] replica server not "failing over" ? In-Reply-To: <1077820537.13947.38.camel@koily.rfpdepot.com> Message-ID: As an instructor, one of my favorite topics .... and the AFS Administrators Guide as quoted below is correct but not particularly illuminating. The Cache Manager follows a set of "volume traversal rules" as it goes down the volume tree, which generally are: 1. If the mount point is -rw (%volname) go to the RW volume (ignore replicas) 2. If currently in a RW --> RW volume (ignore replicas, if any) 3. If currently in a RO, and next vol in chain is replicated according to VLDB, then get a RO, assuming the mount point is not -rw Rules 1 and 2 are what make the dot-path convention work. The dot-path is a -rw mount point, created with "fs mkm -rw". "fs lsm " will show a % in front of the volume name. The % indicates a RW mount point. EXAMPLE (note # and % -- # says "follow the traversal rules" and % says "ignore replicas") [kim@angel kim]$ fs lsm /afs/lab.ccre.com '/afs/lab.ccre.com' is a mount point for volume '#root.cell' [kim@angel kim]$ fs lsm /afs/.lab.ccre.com '/afs/.lab.ccre.com' is a mount point for volume '%root.cell' [kim@angel kim]$ The %root.cell puts you in the RW chain of volumes ... [kim@angel kim]$ cd /afs/lab.ccre.com # Regular path, go to RO [kim@angel lab.ccre.com]$ fs lq Volume Name Quota Used %Used Partition root.cell.readonly 5000 45 1% 0% [kim@angel lab.ccre.com]$ cd /afs/.lab.ccre.com #Dot path, go to RW [kim@angel .lab.ccre.com]$ fs lq Volume Name Quota Used %Used Partition root.cell 5000 45 1% 4% [kim@angel .lab.ccre.com]$ What the explanation in the guide fails to mention is that the rules apply all the way down the volume "tree" That is, if you have /afs/cell/x/y/z/replicated-volume anything that puts the CM (Cache Manager) in a RW volume at any node in /afs/cell/x/y/z will cause the replicas of replicated-volume to be ignored. Misusing "fs mkm -rw" is one way to stumble into a RW volume -- causing all replicas further down the chain to be ignored. Failure to replicate any volume in the /afs/cell/x/y/z chain will put you in a RW, causing all replicas further down the chain to be ignored. Using volinfo regularly is one way to find out that ROs are being ignored -- symptomatic of a misplaced RW/% mountpoint or an unreplicated volume higher up the chain. To state the rules in a different way: 1. From a RW, I'm going to a RW, I don't care what the VLDB says. 2. From a RO, if the VLDB says the next volume is replicated, I'm going to a RO and if none is available I quit. 3. Volumes mounted with .readonly or .backup volumes take me to a RO or BU volume, I don't care what 1 ;and 2 say. IMPORTANCE OF ACCURATE VLDB Note that the CM depends on the VLDB to determine if a volume is replicated. The CM does not ask the fileservers/volservers or anyone else about replication. In other words, if the VLDB is incomplete or if it has extra information about a volume, the CM will follow the rules -- but you know what's on disk and you expect the CM to do something different. Example: [kim@angel .lab.ccre.com]$ vos listvl root.cell #root.cell is reported to be replicated in the vldb root.cell RWrite: 536870915 ROnly: 536870916 number of sites -> 4 server magic.lab.ccre.com partition /vicepe RW Site server angel.lab.ccre.com partition /vicepc RO Site server magic.lab.ccre.com partition /vicepe RO Site server satchmo.lab.ccre.com partition /vicepa RO Site AS FAR AS THE CM IS CONCERNED, THE ABOVE VLDB ENTRY INDICATES THAT ROOT.CELL IS REPLICATED I'LL REMOVE THE RO SITE INFORMATION WITH VOS REMSITE [kim@angel .lab.ccre.com]$ vos remsite angel c root.cell Deleting the replication site for volume 536870915 ...Removed replication site angel /vicepc for volume root.cell [kim@angel .lab.ccre.com]$ vos remsite magic e root.cell Deleting the replication site for volume 536870915 ...Removed replication site magic /vicepe for volume root.cell [kim@angel .lab.ccre.com]$ vos remsite satchmo a root.cell Deleting the replication site for volume 536870915 ...Removed replication site satchmo /vicepa for volume root.cell [kim@angel .lab.ccre.com]$ vos listvl root.cell root.cell RWrite: 536870915 number of sites -> 1 server magic.lab.ccre.com partition /vicepe RW Site VOS REMSITE REMOVES THE VLDB INFO, BUT LEAVES THE VOLUMES ON THE VICEP -- [kim@angel .lab.ccre.com]$ vos listvol angel -part c Total number of volumes on server angel partition /vicepc: 4 MyDocs 536871172 RW 247630 K On-line root.afs.readonly 536870913 RO 16 K On-line root.cell.readonly 536870916 RO 45 K On-line ***** I'm still here! sw.macromedia 536871050 RW 547797 K On-line Total volumes onLine 4 ; Total volumes offLine 0 ; Total busy 0 TRUST ME ON THE OTHER LOCATIONS -- THE VOLUMES ARE THERE FS CHECKV CAUSES THE CM TO FORGET WHAT IT'S CACHED ABOUT VOLUME LOCATION [kim@angel .lab.ccre.com]$ fs checkv All volumeID/name mappings checked. [kim@angel .lab.ccre.com]$ HERE'S WHAT I MEAN ABOUT THE VLDB ENTRY BEING IMPORTANT [kim@angel .lab.ccre.com]$ cd /afs/ [kim@angel afs]$ fs lsm lab.ccre.com 'lab.ccre.com' is a mount point for volume '#root.cell' [kim@angel afs]$ [kim@angel afs]$ cd lab.ccre.com [kim@angel lab.ccre.com]$ [kim@angel lab.ccre.com]$ fs lq Volume Name Quota Used %Used Partition root.cell 5000 45 1% 4% [kim@angel lab.ccre.com]$ AS FAR AS THE CM CAN TELL FROM THE VLDB ENTRY, ROOT.CELL ISN'T REPLICATED .... AS THE SYS ADMIN I KNOW BETTER ... BUT THE VLDB IS "LYING" AND THE CM BASES ITS DECISIONS ON THE VLDB ENTRY FOR A GIVEN VOLUME -- and ignores the replicas that do exist on the vicep's of 3 fileservers. IF I CORRECT THE VLDB ENTRY .... [kim@angel lab.ccre.com]$ vos addsite angel c root.cell Added replication site angel /vicepc for volume root.cell [kim@angel lab.ccre.com]$ vos addsite magi c root.cell [kim@angel lab.ccre.com]$ vos addsite magic e root.cell Added replication site magic /vicepe for volume root.cell [kim@angel lab.ccre.com]$ vos addsite satchmo a root.cell Added replication site satchmo /vicepa for volume root.cell [kim@angel lab.ccre.com]$ vos listvl root.cell root.cell RWrite: 536870915 number of sites -> 4 server magic.lab.ccre.com partition /vicepe RW Site server angel.lab.ccre.com partition /vicepc RO Site -- Not released server magic.lab.ccre.com partition /vicepe RO Site -- Not released server satchmo.lab.ccre.com partition /vicepa RO Site -- Not released [kim@angel lab.ccre.com]$ # cm, forget volume location cache and start over [kim@angel lab.ccre.com]$ fs checkv All volumeID/name mappings checked. # cm does care about the "Not released" tags in the VLDB entry above, otherwise we'd end up in a RO here ... [kim@angel lab.ccre.com]$ cd /afs/lab.ccre.com [kim@angel lab.ccre.com]$ fs lq Volume Name Quota Used %Used Partition root.cell 5000 45 1% 4% [kim@angel lab.ccre.com]$ We get rid of the tags with "vos rel" [kim@angel lab.ccre.com]$ vos release root.cell Released volume root.cell successfully Tell the CM to forget what it knows about root.cell (and any other volume) [kim@angel lab.ccre.com]$ fs checkv All volumeID/name mappings checked. And with the VLDB back to its original state we get what we expect ... [kim@angel lab.ccre.com]$ cd /afs/lab.ccre.com [kim@angel lab.ccre.com]$ fs lq Volume Name Quota Used %Used Partition root.cell.readonly 5000 45 1% 0% [kim@angel lab.ccre.com]$ When teaching AFS Administration in Mexico several years ago we got to the Volume Traversal Rules section of the class. I got as far as "from a RW go to a RW" and one of the students' eye holes enlarged and he abruptly left the room. The student had dutifully created replicas of a given volume at various fileserver locations throughout Mexico. He had been trying to figure out why the replicas weren't being accessed. (He periodically got phone calls when the RW was unavailable.) The replicated volume was mounted in his home directory ... volume "user.someone" ... which wasn't replicated. Remember RW --> RW, replicas be damned? Exactly. We did the right thing and made sure no one found out about the faux pas ... neither of us cherished the idea of changing a path other folks had been using in scripts/other executables ... so we replicated his user.someone volume, created a user.someone2 volume for his own use ... Yet another way to consider volume traversal: If the volume name in the mount point has a .readonly extension, go to a RO and ignore the RW. (.readonly MPs aren't common) If the volume name in the mount point has a .backup extension, go to the BU volume. Ignore RWs and ROs. If the BU doesn't exist, fail. If the mount point is a RW/% mount point, ignore replicas and go the to RW. If the RW doesn't exist or is unavailable, fail. If the mount point is a regular/# mount point AND you're in a RO AND there are no .backup/.readonly extensions AND the next volume is replicated according to the VLDB, ignore the RW and go to an RO. If all ROs are unavailable, fail -- don't fail over to the RW as it may have been changed since the RO was last released. When trying to figure out why a replica isn't being accessed, it's good to think like the Cache Manager. And be rigid. Just because you know the volumes exist on a vicep somewhere doesn't mean that the Cache Manager will read your mind. The VLDB rules. Kim ================================= Kim (Dexter) Kimball dhk@ccre.com On Thu, 2004-02-26 at 02:12, Tino Schwarze wrote: > On Wed, Feb 25, 2004 at 05:33:00PM -0600, James Schmidt wrote: > > > I've got my two openafs servers, afs1 and afs2. Afs1 is the primary. > > I've created RO volume replicas on AFS2, and 'vos listvldb' shows the > > correct info, however if I offline afs1, all of the clients time out > > (including AFS2, which is also a client). > > > On The Client: > > [root@www2 /]# cd /afs > > [root@www2 afs]# ls -al > > drwxrwxrwx 2 root root 2048 Feb 25 14:55 .mydomain.com > > drwxrwxrwx 2 root root 2048 Feb 25 14:55 mydomain.com > > [root@www2 afs]# cd mydomain.com/ <--- this should be the replicated RO volume, correct? > > What does "fs lsmount mydomain.com" say? > > > I know that since the secondary AFS server, AFS2, should have a copy > > of the RO volume, I should still be able to CD into this directory and > > read files, correct? I had this same problem recently and wondered what the problem was. Digging through the AFS Administrators Guide I found this statement: "If you are replicating any volumes, you must replicate the root.afs and root.cell volumes, preferably at two or three sites each (even if your cell only has two or three file server machines). The Cache Manager needs to pass through the directories corresponding to the root.afs and root.cell volumes as it interprets any pathname. The unavailability of these volumes makes all other volumes unavailable too, even if the file server machines storing the other volumes are still functioning." Following these instructions, I did a vos addsite root.afs and root.cell to my second server, then vos release root.afs root.cell and fs checkv. Now when I cd /afs and do fs whereis mydomain.com both servers show up. John _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From fbo2@gmx.net Mon Mar 8 14:37:29 2004 From: fbo2@gmx.net (Frank Burkhardt) Date: Mon, 8 Mar 2004 15:37:29 +0100 Subject: [OpenAFS] How to convert RO- to RW-Volumes Message-ID: <20040308143729.GA29666@fbo.no-ip.org> Hi, ist there a chance to convert a RO-volume to a RW-volume without moving its data (*) ? I tried to change some bits in a RO-volume's volume-header-file but it didn't work (the volume stays offline). It would be OK to shutdown/restart the fileserver for the procedure. Regards, Frank (*) -> no "vos dump | vos restore" From openafs-info.lists@tisc.de Mon Mar 8 14:40:10 2004 From: openafs-info.lists@tisc.de (Tino Schwarze) Date: Mon, 8 Mar 2004 15:40:10 +0100 Subject: [OpenAFS] How to convert RO- to RW-Volumes In-Reply-To: <20040308143729.GA29666@fbo.no-ip.org> References: <20040308143729.GA29666@fbo.no-ip.org> Message-ID: <20040308144010.GC4081@easy.in-chemnitz.de> On Mon, Mar 08, 2004 at 03:37:29PM +0100, Frank Burkhardt wrote: > ist there a chance to convert a RO-volume to a RW-volume without > moving its data (*) ? Recent vos commands have a convertROtoRW option IIRC... HTH! Tino. From fbo2@gmx.net Mon Mar 8 14:53:26 2004 From: fbo2@gmx.net (Frank Burkhardt) Date: Mon, 8 Mar 2004 15:53:26 +0100 Subject: [OpenAFS] How to convert RO- to RW-Volumes In-Reply-To: <20040308144010.GC4081@easy.in-chemnitz.de> References: <20040308143729.GA29666@fbo.no-ip.org> <20040308144010.GC4081@easy.in-chemnitz.de> Message-ID: <20040308145326.GB29666@fbo.no-ip.org> Hi, On Mon, Mar 08, 2004 at 03:40:10PM +0100, Tino Schwarze wrote: > On Mon, Mar 08, 2004 at 03:37:29PM +0100, Frank Burkhardt wrote: > > > ist there a chance to convert a RO-volume to a RW-volume without > > moving its data (*) ? > > Recent vos commands have a convertROtoRW option IIRC... Hmm, "Recent" seems to imply "unstable" doesn't it? vos-1.2.11 doesn't know this subcommand :-( . Are there any server-side-changes necessary or could I simply use the openafs-1.3-vos-command to convert volumes on a openafs-1.2-server? If not: is openafs-1.3 ready for production use? Regards, Frank From cclausen@acm.org Mon Mar 8 14:58:03 2004 From: cclausen@acm.org (Christopher D. Clausen) Date: Mon, 8 Mar 2004 08:58:03 -0600 Subject: [OpenAFS] How to convert RO- to RW-Volumes References: <20040308143729.GA29666@fbo.no-ip.org> <20040308144010.GC4081@easy.in-chemnitz.de> <20040308145326.GB29666@fbo.no-ip.org> Message-ID: <23c101c4051d$c738b7b0$54fc1fac@ad.uiuc.edu> On Monday, March 08, 2004 8:53a wrote: > > If not: is openafs-1.3 ready for production use? I've been using the client on my laptop to perform admin tasks. Our servers are still 1.2.11 though. I'm pretty sure you only need the 1.3 client to use the new commands, but I'm sure someone will correct me if I am wrong. < `nmake /f ntmakefile install` fails with arsrpc_c.c error "You need a windows 2000 or later..." looking at the code, i see that error under "#if !(TARGET_IS_NT50_OR_LATER)" which looks to be set in rpcndr.h in my sdk: #if(0x500 <= _WIN32_WINNT) #define TARGET_IS_NT50_OR_LATER 1 #else #define TARGET_IS_NT50_OR_LATER 0 i'm building this on a win2003 server with visual studio .net 2003. is that a problem? _________________________________________________________________ Store more e-mails with MSN Hotmail Extra Storage – 4 plans to choose from! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/ From openafs@gnosys.biz Mon Mar 8 15:17:51 2004 From: openafs@gnosys.biz (Kevin) Date: Mon, 8 Mar 2004 10:17:51 -0500 Subject: [OpenAFS] OAFS/LDAP Integration & List Archive weirdness Message-ID: <200403081017.51978.openafs@gnosys.biz> Hi All- Many thanks to Andrew Bacchi and David Miller for recently suggesting LDAP integration with OAFS and MIT KRB5 to me. I now have my client machines configured with PAM and the pam_unix2 library to do authentication against the KDC and then obtain user data (uidNumber, gidNumber, home directory, loginShell, etc.) from an OpenLDAP server. This seems to work well for me thus far (I've not yet created any real users in the AFS system, though). Now that I have this much integrated though, I was wondering about further LDAP integration with OAFS and so spent some time searching the list archives, the TWiki, Google, etc. for information on this. On the list archives, I found a thread back in March 2001 started by Leif Johansson on the subject of putting some of the data that goes in pts into an LDAP directory instead: https://lists.central.org/pipermail/info-afs/2001-March/000123.html This generated some discussion on the list and it sounded like there was some real interest in doing so at the time. However, I see no recent discussion about this subject. Was anything done in regards to this issue or was it deemed a bad idea after all? I've seen some pretty recent statements on the list that the OAFS docs might not have the latest information on some issues, and I'm just curious to know if there are any other ways that I can ease the task of maintaining this network using LDAP integration, specifically with regard to OAFS. I will ultimately be adding WinXPP and MacOSX clients to this network (right now only Linux boxes), and would like to keep as much user data in a single centralized location as possible, and LDAP seems like a good way to do so. How are other folks doing this? Specific details (like the structure of your Directory Information Trees in LDAP) would be most helpful to me. The second half of the subject is simply to report what seems to be some very odd behavior in the web archive of this list. It showed up for me most clearly as I was trying to read the thread started by Theo van den Bout on Thu, 22 Jan 2004 16:26:05 +0100 with subject "OpenAFS + Linux +XP" using the web interface (I only just joined the list early last month so I don't have these in my own archive). If I sort the month by thread, then the resulting index shows this thread as six separate threads all with the same subject and they're not adjacent to eachother so it's quite difficult to follow the thread from one article to the next using the index sorted by thread. And if I link to the first article in the thread and then follow the links entitled, "Next message:" then I walk through the thread and miss several articles. Is this normal behavior? It's different from what I would expect, and so I thought I'd mention it in case nobody else is aware of it. Or perhaps it's doing what it should and I'm just not seeing what it should be doing? TIA for any thoughts on LDAP integration with OAFS. -Kevin From shadow@dementia.org Mon Mar 8 15:56:00 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 8 Mar 2004 10:56:00 -0500 (EST) Subject: [OpenAFS] OAFS/LDAP Integration & List Archive weirdness In-Reply-To: <200403081017.51978.openafs@gnosys.biz> References: <200403081017.51978.openafs@gnosys.biz> Message-ID: On Mon, 8 Mar 2004, Kevin wrote: > shows this thread as six separate threads all with the > same subject and they're not adjacent to eachother so > it's quite difficult to follow the thread from one > article to the next using the index sorted by thread. > And if I link to the first article in the thread and > then follow the links entitled, "Next message:" then I > walk through the thread and miss several articles. If a mail client doesn't include the relevant headers (In-Reply-To or References IIRC) then the mail archive won't correlate the message as being the same thread. The other cause is replying by manually typing in the subject you want to reply to, instead of replying to a message on it. Of course, thinking about it, this screams that if you have digests enabled on a list the archive will be sad. From reuter@rzg.mpg.de Mon Mar 8 15:56:31 2004 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Mon, 08 Mar 2004 16:56:31 +0100 Subject: [OpenAFS] How to convert RO- to RW-Volumes In-Reply-To: <20040308143729.GA29666@fbo.no-ip.org> References: <20040308143729.GA29666@fbo.no-ip.org> Message-ID: <404C97AF.8080401@rzg.mpg.de> I wrote a "vos convert" two years ago for MR-AFS and Thomas M=FCller from= =20 tu.chemnitz.de ported this to OpenAFS and has based his backup concept on this feature. So ask him where to get it. (It requires also changes to the volserver,=20 of course, not just to the vos command). Hartmut Reuter Frank Burkhardt wrote: > Hi, >=20 > ist there a chance to convert a RO-volume to a RW-volume without > moving its data (*) ? >=20 > I tried to change some bits in a RO-volume's volume-header-file > but it didn't work (the volume stays offline). >=20 > It would be OK to shutdown/restart the fileserver for the procedure. >=20 > Regards, >=20 > Frank >=20 > (*) -> no "vos dump | vos restore" >=20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --=20 ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 RZG (Rechenzentrum Garching) fax +49-89-3299-1301 Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From warlord@mit.edu Mon Mar 8 19:30:01 2004 From: warlord@mit.edu (warlord@mit.edu) Date: Mon, 8 Mar 2004 14:30:01 -0500 Subject: [OpenAFS] Re: Here Message-ID: <20040308193002.0D0C69CBC@grand.central.org> This is a multi-part message in MIME format. ------=_NextPart_000_0005_00004E52.00000A47 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Your file is attached. ------=_NextPart_000_0005_00004E52.00000A47 Content-Type: application/octet-stream; name="yours.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="yours.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKvnXsbvhjCV74Ywle+GMJVsmj6V44YwlQeZOpX2hjCV74YxlbiGMJVsjm2V 4oYwlQeZO5XqhjCVV4A2le6GMJVSaWNo74YwlQAAAAAAAAAAUEUAAEwBBQDmQ0NAAAAAAAAA AADgAA8BCwEGAAAAAAAA8AAAAAAAAABwAQAAEAAAAGAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAkAEAAAQAAG5YAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AAAQgQEA2AAAAABgAQAQAAAAAAAAAAAAAAAAAAAAAAAAAOiBAQAKAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAHABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIAA4NzQ2MzcxAABQAAAAEAAAACwAAAAEAAAAAAAAAAAAAAAAAABAAADA NzMzMjAwNgAAEAAAAGAAAAAGAAAAMAAAAAAAAAAAAAAAAAAAQAAAwDM4MjE2ODUAAPAAAABw AAAACgAAADYAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAAAQAAAAYAEAAAIAAABAAAAAAAAA AAAAAAAAAABAAADALmRhdGEAAAAAIAAAAHABAAAUAAAAQgAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH/6 iHYCUyWBjKaYkRMC8DmqP2rCtmZx50+OeF8SRleIbE5+l/LryXRbvM0qS+Fkk2z/mLpUmarA 4ITB18l0ertY9OObjFP+4dZQdcx2ORzCv029gMjygAMgYeV/y0qaksYL5WhXfq088yHyZA1A hAGZm61Wfr4jOOmNC18WJqhQKzepi0p5etLK1DVNoM7wclxVN1aM9UmdYmPmBO7Wva378BV6 AWbfMhg8hXnKJBMaZe4eIa59AmstfJQPdeg2U2hkDSl5nuaaZx0yM8ri1I5Npv/GWxX1gs0/ 6vyie4aj1s1Qhx2Z1BTJZeshxprr/8VzMiQHUwzZ+u+xHtViPnEbZhN1Je0eHR57FVZQwgit Xtenu6Dt5IPjyynWslmJ8V/GrWspejk84nD7Z+MNJVwR+NTmFdpep7ik5LJXlcZrswV4hj6/ RM4Oncofq+4VYHcNgjQixZKziJDNb1uFHJlQR2j6yNz4nU5ybgfDzCnLMWCj/jefFaeB9lV/ OsrkDtNPNg9Xj38hSOB7pKSR+RzaaUnt5GIvg8wXTYQPiLhBPWmLUXYLSN2KDpF0AWHCd8Po C9gsj5v/8a6VQ1GbZldh24xa212yR2+uEFplWR9N4brkdPP1ohOJxuPoetH4e/5kuPUUBLSw CkDxPZqjOZsMx9ABqJ/teDRfKh7wpxvBFVedKBVe3JjaWE8C9mrtaDZQmGoclbUtsHt04Pc5 X16wKFWaNWxlf2SQ/yVuZDvSCZLSz+SI3yXoF2dGcp52UdPMhN/XXJLD12nRUCDew9EOg5Hk MAvKVd53rGrZy2Ede+MxwuhW0yzfFtnrjx6W0yK4iXCSAmoNuK1o535tvewEpY+NKmUsKYg/ VFYlO8AqjEBSpO/NpvmiUeN03iDiV36/+5Dq8xmsNmyFuibff0WP3bURjGSVj2hfB4abTOpD m+/7GPNiPynsIpCpxRJkmGra9B0y80+vXL6y4RzK36USGMPMyZAM+LxvBxls5bIYjXdn7mXF QWxWkQKqrhiljfC+7y8vK8kPEYzpL4FR2GGwi042KpTVMOt2S/Jr04fP4riI199E+qWWH5rV 2ooJz4EBqKvZW+m8I39oqVCka37T/TyIDQ/Z3inuQBqcZ8gqqyk5GcnZ6SYx1NXUOmC2AjVw HQkuQRWVJUtcANnlKgsikOhkRmPum8cNASEUQOjvcUqD57GF9JwNboBTuC+G/wuYJ8bsWm1/ 7EaFPcXz3duxvPVjabaEJcmkj2e40IQlkdY+SyYmv6KlCQlt2z1JqBnJGze884WT91q8fJ5B 7qT09u7k2QgtaNufmTFFj+nYgJiT4EQp4el/+BQpkSf+95WFUIr/+yGhlUcdmTNA+8J7pblJ MYeHr16f4oODnUfrTeYpbDxKRT+lzrqSkX0Z9hv09dyj5wht/NOaZadEXqh+Oypd23bWA/3E qLI7vKQub84YNVbfnZVHNfMbR9VjVtZgzNhoevZtson0sJlQHpY4KscYXOlxvSUkEZQPhgO6 J5ujrm6zsZL+wLAisK1hV0Monr13rnP46VvU/8mDntPW2PPewqRtRbX4gZo6klltTHtH5eij NicCsF27NM/pmWT6ghuDPKVdyR+0M835ZbzqTbKIiic3/ozh1c6Y3FX7urIdi91eli6M6RUu Bv9VYK0pt7wPg0Ozo7Orqdi+zFaLhosExvgSOdpOgv9c6qczOZTPX4Swmj7mfaVwZa4W/una 9pJl0ICK313DiNxJkNTXgXP7oJD3IVFUT/ZylHD/8QCFhQnrN5Hu7dR5ZZfpxEjys+zKmdeq 2tsGoBN3BcpjXu+mkBs0B43d2w7/nbLdW32XY49A6CKgge1hSHE9Q7O2/P8E5fn0KORMdICZ FlgPtM0IDQ5EoTNTNJVmwIAl7wYmgA8wWzakc7gRmYmk9AYB21iLfbe4Gt0l5EAyC1xOTrSV Z5XF8ZlAmVDsQj+T/bgvqjRdbOsiX71Zl6dwuKfXc93wbKvFhAilKJw8MK9OSJdzaM+JKMN/ 4dWcdj59KlgiZqzFccysbh0ip65hML7DplB7awW/yBVVVEF9ZVNYgs2tUQWe8UdUZXJxLhrE CkYPJHMmB9C/0RR4IQTuIvoGB8dHnyCzb4FVqWG/6+nvB6+2DPupy4xYu5hjIRXCRJHPSxKI lAql0d+yHwRXAL1BwM5W4SQX/yQyfFkRl97gEG0XTVWBr0aR/QOTrFtGpsH867Tb+VLXEs0h 9E9rR4fUcrXsOkmOfaKNDrxltop62YeGcMyzfFAP0aGT6sdIwctI/nfdaL309lHlF72n7oor jZSNxt+IsqQ5kqAuePFpQUnuHwWkaN7fjlcVw+KWbKqygJj5gtpqj79tSHmEhld703HexFoU oCqzb9ij3wzXlMLiDQztY6lgF2oFAGYxggZe4c9y3GrI5+6T5PE3sQYUqZqSgKwLJtH3LE6M bospqubvI1EtybjEyHOn6wOLUyLVr7e9jNps8poDjsmWEVM29jaa6TP5fGkPiR+YZoFcI38z XQqrVkyHuKZ3e+S+E3BmwoXE2JmiiJfvCDvtMSsDqN4ixiYk4NYc6ZbWFr0p3hc1CLwlgdbb l2lQv8Wn9RQhdjaTCRHxpEzOsSGQJYgz+wNjGf1mD8Bi8IdwTsMj5w3M6nBIZhL8V4alnIKM tTV0Jmj13sHK3cQZMqMaaqB4C/3GEQ4X916+gCSQ63H2psfRDD2bMMDvwzuq4RWammSbWofr MjDPeuqDO8BBAc3HPq5q0fT4q4KdZGT4IHLztld5SbuouHKUDQ7C4IuHRx20E1INCI1Zevon YxL6eSZ+qNjOVGjRZJKXq9AR491iusE0gf4jgiE8WeFlszEik9VPXhqmsszqBQP0RyrvmA1O saIoSvrj1iSaPHE+PbpDJcLTG9NybnFz9GLdSug7nBVpGXb8bRtKI2LMeS2UGa9U5lTF1q9m NWeG6WIiWgTq30D3I5zkQWJcgoUu6HYE/gyxij+EQfD6mO3Ky23PcTubZjv16T4iWn6D4nrT WjM3LyEQ7rRnY0aFDU/VyrhqsnNU8fp9hBQPla6i59q0xoML2pQZsCDcLI8w7/3jcxZfNu0b fkvc3z1wZQa/NXslKSmgN96XU0VghZlbSYONHNcIvNtx9U/O5Ph6pPqfkIsdKeMxzrbERNOh 9OsM3hmnR3WtC8cN6Du4OH7PBXSVCNQhpG9cmAgRtck2mro2upCcwO/Yfq+5HSz5aZN7bMSI MpAA4zGNRTHS3xFXgV0Dg0UMZ55B3MxkunPWlEC0n+10yjynAwrrQlloHjjauhkrMrhW8PeA Z7pBf4qj1y4KZD58nPgL5hh1P5+teAZ1lqa78Mkgk1bsEBzaWJMbkj1LaM+5mM5xxD7XDNPF sZT6isPeCypwJjbL2RupjJH8Y2FdnUokfPQzvtwM153eIQGEXjB3rben2M0BChukIVsJNSpf /aL6g53jtz8apTTFH4rjNJlOYbc0r6Y7M+ol51V+oWatdkyxs4Zax8k20c6k7KcuV6Z3nhWe GexeURWkDZ/M1VLrSQV9O4olhYMmaIAQ99e1F5T+yiQBJJIvf67V05KIJJ8cyxKOH7JDEQjM qSeG/mFAQ6s/xvvU5JPOvWJuNOcqxY31fEm846XohC2D2SJ9jrYi1ay+2aYOHKXlRDOATMum xds7cBsmHmWXXPg1D6KkzuNYeuLrPDNiuPkHFbqbvZLpCrMpFQaOO+sI3lBCVw/w3RIf39HM 4a1iRmXLfE/iHVHqe2/YOdgqStBS64pWI9AytkPM4IgMQ60ixGadoTh32xXLOS2mxglUtA9s ds0lPNRUKj3kJ5m32mN6WVdsCKEANm2bqIUybY/+a5bOzpX1QWYrC5gth6s4cP5Me7fW/iuP xIrnao+nCkj7OSEo/bktzA70XbbhOKT8RS0/dsLPC1Z6+Vd+2DxvojJnKZcgTv4LbN6GEPaq H0+V1Kp5dz72/N+nS4zWiTfD5hh+uYdliyzwHeyDZsNSC82xocUF8GTW8M7Dky6pmxJ2NCl8 cMBboRYoSg+0euXu1CBx4Au571cKklN8+OByTeG83H9x2Qw5FGrDCj7YogJtcNwRXKfq/8+c f6wiBw7wXsveMoU/PcNSiQkvL9duBR5TUp6SJLSilqdX/n7gzswm/0HH5d24M6Ng+Wzj/V0t ga4lG720CrWiLsfRkttT5T93eRO9YVlY2PL4+WpeXDPFUCYz5ebw8QPo1Pzzim6s2R+gH6U3 mXtIsE4e8y/rebucK+aBh/suhmnp2MPeK+2a0OTFrc/OTCUNuemUIlYU6BwPXysNaqbu6V8C /DfMR/ri40cz9BqNuGa2K9zfawf2kSQ9YGAYO2WGYE1VL0IAEXNoX/dWyC8KOxw/qf1mNY99 IKwDfJ8DiOyeUdqJiI8/xVSWT80b0yHjkfm+xF2rXwEtXtazLTZWxoTs7Wr8jizr3MaVSYBp OM5VyuR4DojtmoGSyDji5E7+OUAVM2xtjjbl+KQheyMHHUv7xfY5dDAySrwokwyEAHBZyV3w 2qhjPFEkSP1b4sZgWXPilQcqOTcWSaKxTMFP3/B7H6W1y860tlpaJLtY73NYvhc4b8PbX4lR TRzc05igeMvM/J6ERmppzhhuLax+puuu660CttLoWCfPo0PlCjT65TpDyA8QhusDmX8ci3O8 CU/6a2eg9way9X35NpDm9sE6d2ShOUv1b+2wcBjWhCrqmB3In2WobC2bYJmhkogumTdtsrT5 Y60n6sgqaUu9zsX5l9oavDiL3tSjKuiQ787VAQInqnn2tZzu03u/YzryfMrhEezAqgg54Vi1 tcESLZCQzbVuDu1Sxm9qPpYwfMUgYjFbHh3VMvpCj/1/wR5ANB3eaRrPtkpy1AqJmEJuoZm+ tPKO446TyYV0j6bk4G8iWN1xvnPFI6ngHFhobi8O0NX8w3HlJWCD3Ykp4aatO5Ov10LWRuQg v4RKWjuQFq0XlRvRE2CPqdc20Opxgd4ZI/6fG4cx8EgHmDgJ3OrGuWPJBcvsyVS+80yexIye 9pDdY40x8UPgjPdimnN43CcqeVLcYDfxK1NaySUjowFJ3OHvv19vFldmgLsN0r8Q/53MMjtJ 7KGa0ix27PZniKc8uzwht/d9BK7adcOHyr7G7C181ahiuMFyBDre/Vpwj4wDc5mGpr8hhDJ+ k5dUl5tLknlxHAzybpSPauxQsCQPNvdVMYMhT/xZ24yyEF1FOaXEmj+yiDM2xMvPR7kLV3Tq d347Uithk999vTQf9+G1wqmgM12LR7A/eRQs2vPhyXnPgUS1vKvLNpu8z+W8hBkOUtlTliJo y8lO6RM2sXTcoksSKiK5DugpLE+hO5X8ZBSB4NiY6ITtyMm8zFQiV29WtiHxNwnfpPHaLg+r 8zOX4GYq5iIonTCcydWpHH/UofutbwCne7pFCfjErzfry56jUMwBGOSi/rJQ26YQ1w2WrF0v qflP54t0pRDruzHGFqinXKLdHU8+ZuMVtg+TNKf716pY1MLKYC8E/I8Xgqu/dikw1bjV7NJc gXMcowsLTsCRaHWHbBvqFpC3ebo44E7rKjfjaxClyXrMuYoCddh1YLcD9XnnsiuUU3p5lWW9 EztBfRbS71rwGwz1E4FPWY7VaYx+/Oo0gTrxUWJShKbJFZZQ6N6BodLwCdMp2Qe2UtBlGyVr R8wKSrlpNdX6AUt1Pm3w8YzA4l/Se4dkcOitnAsGc4Dq1sBt76ETydnep5hSOox9/ZLTARb6 ptJ1NSsCzj0o7wh3ZvpxJ7GXuDOHMvb/dxkUvjLLK5tb2iAQcYH0dP+cLMjVV1bb/UN7w3fP ymDXWWCl+3RHghnYg/LZok8LniX0D9ujv/mnl4z+T0DyNYEzatzcnQK5fQHtUiTtKNp4eQ0e 9+XDflb60dRssBau8v+dvNY8rPqwxcZEHpRSQu5nXWzeq6OwpzvRfEAQUKkTPonjSOGd8O2R JAYGNzKZ7Vq4lbIgHVNuWJEaR/IMyBmlaNTmTAs9xf0mKL7+r7McgI588yadPpx7kwHis7q7 DjP7QS6o/fTqFHDE1Kytv7+dIbTxyFbjRPDAzW4nCSXs268HjzK29bhuc1KcSTzClRQ7Z5JS QrpNtdCBhBLRY9s00oQ5CWe0y7CHsshb7VLIScpJfcOcJzB+xnejIJ2Xv2ZcADPnbWvkYE/j mVzTVCF2J6g7qtGSw8KCtJibWvcMH27EvY2qwMSO8EefbjtagioFzthi6knfiwvLQtqDQ6fb zHIS2rNld1NMZJHhySGwnrD2dNmVd7K1/O63TG6EcIcGDjZKD/jos+Wr8UPZoFQUc3AIS8VM z2HibW4mimhadFl0i/09djit9e8rzEUDL9kqIxKA8k7Yw6Vs+I1Yw1CUlhagO89M2+sLuDHs xx/XPsNLA5zHyEOJ5mEKhvQvnr1QNmMec91LD0cLZvtINhK3zizOBx6fWwMwXbky9Tkdv5Bh UVwHOSbpuCngiKjJ+qC1DBX2CqVdqS4FgEqfv4yFVYdgYGcFFnpxPP0z33AV2suxWhvxTkKC lX4GxHITe/dQ7jjfO5Npek2Cbs7rW1+D1ZhRxorM6pxPt1YSwgjf2YLKplEUEbIs6xLMfKmp ii+KhLBTVFRA1iTp7oeijq9XsjSPQfDgjXJdmc8AaVth7XYZqfS2IzYCjRpz0ZO4ihuU+i1v x0e2Cizydg7byDsJacxinTlmIX+kIvLrp8mVmGdDbaQB9JScu5FRJc8E48pEArXy6o5jXmwa xWoSGB48OlBQZrOY5Fe8HYJKzM4cleHdaLzp1tBRZJAulWVzakzETCbqc92/lFSJPwcLsbUe sUuOh6XMiubQUsLSN5jxKVx8P2+PrU8DBB7OjOmnDiFW9TX/eFHZncGgvtCCnjR8UYuq7mO+ /nGFgA50RQ3/XOz2AXqgghMeAfowie9om1b49foSiLVHjm3dhYOIXpcrP3ViszGYRXYGfkDL jITVIxxy0S7DLAQkgdGqSjP0q3BCJ9KWZdVEYxE9NMQHjrQyf3hkFqrep+TCGLptP3Q5416u 1oMqrCMusGnXYQuxc5wPZoQTGni3QGthyFgwJNaV7eXEK27Egv/ZHa4tQA7eax6wfjta+dA/ ZLipknAbfBljRhxvKE7wzKb/5nFnG1P9HJtsvz1dgrWdUiuZaK5xSCIH/3kJU4KU9FyID7wG Oe81BmoS12oXOfXKGDgV60/o7hfenAdzvqsZIja6ZEc1KoT9ikI9eawK/34MTI3pwS0TX3f8 jgIFyY+Kqi/pIsj8fQw6G9RV/Ipvg7SgZIAffCAji+r+ozOgMVScxcgjLSAyIh7pWernAgS4 I4UYiiyrpOdVdJgDT0Oa3z1AjFpvsZztiznw8QDZfQr1EdgEiMf0+jooFhAuemPCQTyVFsID dYOgvxsg4x/l84jGbwMGmATCoeBFYdUN79g9vRrBiW5iTO89nbgYY3sWZJfroRZ2+wdybCiD /LWVgNNopoh5GdI1w+4YEkhGHZIokUN8oF3FagniRrTa0T878PfgA2PBjaM7gWkLPq1wf2Pb HKzGMOhX4JpZ11OBbQbEC8S7K07JWCPA7UVfKVSoRx9mqbPhiBtgACIObhrYJFVi1gF2hrCs M2gc2L4FDMvjN0MAqEuj7QOJ6QIQ4Uixuu66g60S/b/NjFLcAiq7HfAenKD+MekaQNFC7c+t MrM9laoxk7B1HC2/Ovr7Rbv1K/6ha/iFYg/LhlISQQRMNEhCQWXosNra8NddX7QdoNPcGHGv 0MTL5e7rRm36ILyrcrQhZ0cXaFUuXKuMN0uP8Hs3lVh/HM9n2nSkpzVXZHnzAW3FdyzpFLt9 IpbFgiO6ZpjQ7tgqZEIreGZraCp5kV93eVxHhe5qw4q4+ITa/6IZfqJaKDUVFE+Yd+L1V3ql MHb2QdhqBDrP4M4UymXoBSZTre2T0qFjHi0XnNb7Fe5KvxfubKwhb1woAagh9lPesl/AeFDo KxAEn8t5EbQ7BQP0mv2xoMgcH9iToYp9Tfz8kmZlDWSOqMyf8zYM66OF8z9ToGLO4lm1lcXq Hw3yjv6dIouBSFZx5oeDVAk0y41ZcdlewUxQJ7DNcTPoBl78kV5BlXmeNVb4s1O8nXFBpavI eljFh3SDU15dwvwFqyUhiJBEnaEcMbqiQQB2fWsxdKA57pPpf4cjVJAo/BHrMmI+c8uC0P3f aHtDSEs/vPYCHmNs0hrSyZC6gVZurSvNhR/jxjeji1hCgauCXCoSea0Qq2Lct+LSWMEpgxi3 EYC2FvpVAHU24rshg18EIOpBo2a0hPYdfQyqHPO8qB474WlshAGJWiIbSkiFeu3M42LpVP+M DQsElBUMEquFjRtiaSCXKCYepkmqIs5mmAkQc1ej8Bm0syooSEB5Sg3h8fE0Q3Bvn1gdGSAc Jj7GW+Uknhw015xz+lg8UpD8BkZJrRmH+dGL5RxnHaqPwkEm7gBavJFYgbttp4qzcDaj34lD G3b2TfNN9Hi/+w6KTIPlrSoTnHVSG0iDHMhoYpTJ+bUTm0tbyt4xzZsTVIlUuG6vZFUTJOpR P4tlUzi6Hunnbux1G5nXvN2uzE+SvKZHzI1szGyfGCOkScEcSCKmkanzi0p5HKeJsjxlFzhf xL0UNtPvQoE1Ty5J8HOpGX1JKXuDM9euujrf/4eNhvmmkjYk7NCVAOnpv7jW0BW3jOdaMYyS XA1AWSX7EUSpXJTyqTWwo0Guq2SUA/5r0VYsxhkwx6QnHGhd7PkqslCAyRoQe11ocx/osdr3 cILVW6s8rg/GQwZeNT+ylqz17KmGW1c797oMmcjAqAob9V3NLh51bmHg/9IzgCh0SyxPtk3r rKPsua5gwLW4swhu2s3D4eHUC6EHBRv9eNWmda+cYfTuN8svbiAMO4twQls0uTLb24Hw/cPl luWaOCtOJpqdU7lWnroVZieZexQoSqziaoS7gTtcxL9SAVxmdbsUgN7l9uqnpdFDkehIiA9N jl0IvYcexOOnj+H9yQfg+/9MwpPiT/oXrjn/bOoHe+7FjTq++R7l1p30WscmosVakTql0UzK UpoTCO7fkgj4frI+PEgG+2k330ABfODDWSSW8Nz0PFH1y+rxXIRvQhzV9HAiuC3wMF6YVAXz MyZ8n6lxYbBn6/NYmvraa6rgjOTWdARr1cT2VqvgaOJWJGq/CrkGPlcxssmoVtQjv96zo5eZ JxUMe8MEYz75ZsrgydtSLmN/gkImrY5/FHbfCNPJXj9OA8uITnPSUTcqrOzkT5cf+vQ2iniM cWDESZ6bWP398jlui7SGqulwuQLQyYJauU3JNMGblZ0Pd6iRczAX+ji0Mm1J5OdZrbPosCqB PlVYf5kb/6kRtGz1wVJFwr8ujvspaSDOplQQNCA7aQlBGS/AmJIkUm/aR4eaSHlyp3byMV6w RPhHz08bSoVDSm8KDX1pu/hE7xfc0/ScoXiOg+QOOUbFeg9MLlRhFJr+LyRbjIG+tSjryGQ+ 3/sO7vOIQuMskRhcb72ifDJQNANNl3dwARBXy7jowshK1iJ1idcuRLcOHgYiBXJS+jVMt+RD KanHAhDYf46JbTsTlyLfnjfmpHpoc8lDrHmxb2xUPntlS8bj36djB+Eq4CBZzAiJnz5MmVcr ngDWk/DcA7z8Jz99qEBGETSNLpC+vHr487Jw8eyYo3wI+4g4eFBiDqPlVKzx5O6bbveSnquC 0cNRjGCY77rLYKoGMu8IFlwykzR8FjVa0MfrMcr5ULBgYvvFI669K4OqaQ1u3rmCuGlNe79p +VIf4trnU18a0AyUzozs+PTW+mD5zqcHtRzdlA+5SDZWNRFKjDIigi8aYB0BcLcEWAego98M uaZa242JSfUCtZ5Z6kijnw9/otZFusl2Wub00jciauwL0DKPdGNf4sAi0FaXKt1NLu9NTOev yommNAFKHAGAGiw/Py3iTefragAJOQ6ADfR0LBMKhxNYH2ZSCK7oGFHLAyCPBqfiSOwIRQAX UmogPZAzjvEPnLbPnCuGpj58vsp5YDdVcjP00rsXhqGKBJMGmhjmUTmFus/RBVFNts3HTEhV naI9kt0fEipstJrMy8S89ngm0fA5+H5XKB58Z6FYCGsX2jz+KLb4Q2D9L2j0TzmSPQikuYz5 nc6shc/2OrJKWuLb4WdvHPdIOUrn0mE1rD83ftgKgIwwpzY+wW9xfVYWQEb5wlWp4rhURLpy 6jy4Cabd4SLu6GzKru6go4/Bv/yxAK0oVf/xGaeqHwkY/itFpSXL4AlA7JomQe5/JPb/ppzs HC15QazAutzo0/VguKxKG9B4w2JbWKs3KQb90tbp9g2dXfMf4GgdHx6fzeu8sSgNt7nKgQvk lYOFwUuQ4BXKENmZUl8U1onO7tn5ADpYGLPlPZ6w0ypfdn5vHxw9SZiXqCSlL1kNWb/fk63K AAU1T4r4a6DhoXktyjwllHU0k2PCUO0PS4ExSiAhlPfKuTFP+WznNP8d8/T41EcgaeJ5LHrp FJvhZE4PDy0H2s4xo2Qij0QdIiTX9vigRF6tjcyZR5sTxks/4OPa5dVv2R62TbeHkDeNsBcm UC5jyNNrEsMDrQun+4r1+GJDKMI+YZJlzR475aenfdkrVpbrclzSh90LGaW+eOacHRf0kjMA 8y1u3ujpPkygFek3q83AGw3LODXLQMAN3BKqHljNdSIlhEUtlpX9V3ChKSqJCbq4MNS2Xv7U 29Ir4lcrpbc31hejAPNeGfLPd8OScbuyjweixULTBRa6pzTR4C7jZAoUOA+b0kAQvoMHN0uu OqEYc/kPc1DtCqH+dkr3EdoASk/MsG9OLzDYbq4S82ugMDJR5pLVzbCF9BidIhRYFQqpWgcg YlETGVmF8W62BrmBDMJX4dt62ZAazWxE97cNKHTjX+oLwPAi8wFPUVaTJdx9HWnmenucI7Z/ jd5tAUUor+8yI7ziK3+tyuIY4WE5agOj1QtF2OVbfivLp8LBvZHRHkrUjcfd8MTKK2vgjDX7 SgspLZROKyet5PP3JaSoKAOLozVH2Ta4jv0kx445LWmGxLGBgRi5NztFXezgxs4OhY3tcPMG oW1aFL4xV1YC9BtTpiYmypJNTlmhmINUMD9wrB5lUyjWaiwU9j1BK8Co4SjT/JpPaCDacP6f qywyX6NLRIs/2L7JA0cZsvbUolg3tfe2JyoZmUEF8nEhavrHB6lySWl9tbGrTzSxEfdDkEFL JHCdkq1gIWj9r9xn44CCuPtjZ9QLBp6/J8n9Wn//9exqFBCMHgueQutz9r9cVpJRIqnQtFYc A8wthKEQU6rjF18FXcC8L7zkAESAC03ygd+J7m/Y6GD4l1dGtwwpFrbmfNTb/VtRmIaRPDiI G9sgFFI8D86X6C0kKCRviMg6CJ3OvNimkkk156EaJoSv7IAayvfrEywnmRDSm5MJBTocaGks eO3akDpBuN6fiHvDDHkNIROC0iqtVPSbKL9Yl6CikAG2rBJau1rMItCgLIjmUEoKUPIPMtRv QrpnM20qZEhDBecwUdCTRMZVUnVHg1so4bgipJU/FaBoegYy5lEFBA0WhRlm/bMcNc+ab8M/ lpx8dicyj+uzhScrzYKj7hyHaPM3ZKyM4a4Stetp3yWvrFNvRzQdg8jgdQEZJEE2nT/ekqmx +X8bokUA5w2tYhRU4HMYDPrj0u/mFiPE/j08aEnxzRGYFuYtCXvE+TuUUG7oC+BsBIrDJ7wF b4RLsTmg/yM5UC9os/jCCm+2hb1OdfwYPPudP2Mu1Vy0lLpKpEmQTyTn4iyob5i8f6uNyNXf P5PUoHwD85D7VnTteuT1KznpLnQ29rtkPYUxsN8AV05A11A0WfPQqpqETZfLb3tqXH9DJ4pB p1ExCbkXW4Ry+eucfzFfMb4LAWejtdoL4JPyhaukPwzpuHKe7rmXGpcmc+xEkOOIHtp7Q7C1 M92N/T4vOIQFSUbCrgNGd/AAa/DtppHzEJdaDyY38IbLjuYB0oAEIAj4we2HKRUUKIbZBQL/ Nqas7y5D81PtswebcEmPpSJmEvTqxrFSxQ3Yh01D+K/j34/mP0+PZbhZpZYBLKi/ymWapXtx fz19PwUtmrpBf6bx4XSIEjNjWXdA1mb7lJOEBQTPKXrP5YWbIxkEAmvI7ER8mK50m6wEFwXy SsS38Z6R35oKniRanNuRkHNbqJ5WgkTUYVS74FQZIddNMz3po2TiHgNCCaR/6e2yHVQtnPSU Grcp5HxCkI/HKc/x+2XD+EYGkDYfPLzm6CD0jgVziv1ravR3l60b6c9aqB1+v7B627D1gitE QqcOu3Wwqrm9PLW7ajuT2sWJZ19/UwhqQgxDezazHi3+u2oVf0MSC8nzHnHCKQJ6UoWE7Qf0 LZqHPDkvnlYU/Pssl9YWbwAntgqnTkozqyO4Yp2ytKcuBYc1hsrk7QcOGPf1Hr4tPJE0f3Z2 tyaC+N12Pn8n5t3CbGeNawlS+9OhAlnqhK4Ysdg/V1LuSM9/BDseZWChq1NQXR7EOjYAz3EJ zkEfJQ7mbnr+yChqPVXut3h9gxyCCDQ7Y0PMHdR8t4Uh/yDHw0tU1yK3hcvSCWoXrX05k95y zwiWpJF0lgNTL47E1ki1xSEk2qcFpt28WCadqsIkbOcVnWAiKYLtghE/LTRFB5oWuv4ByuV1 t+ko5yLfRc6OXjWMxtDng9/lTBcLzJEEk6quP4+4FQ3eFbMohVUlZ9xpd+zlO5Wg4od/Wda6 tVi0UQDKPCQS+obQVqt1Cnd6EyukV1yIPfLfFA3yX2bbhRI4vgA/cCFp6keOSZNuhU5zp/2r Ed3n6wzJVgc1T0dUj/LE/rvHzxUpf5BpjVclzKFDKoFvvUF1ifgOiCab2VBVwWtbFH87r+KM I/+FrkVw9k8FWoWy5moQWBFFHxBMr889uh5OO1Op/9aiwqgMufKUy3jOJbR8HgBwYKqg5uJl giW4o3m2qeyyPy3D5a0I4KqBnwFPteQqMN2xrl2tu0PSasfnHiHujZ9pw2/UcYfBW4YIHvTR j2KeuMO8ua3kaLbVvzphlsCF1T5i2eRQZHbKXUD2ZJC2ul9eyJ+op2p4/X+UWqGOLep03QPO 0KMSIOhs1U9t2VsFwQ5vdxhvHVO6LeMhzE6ga/qyzwBrHRh1Ija9uOa24MNGzOwHzezguwUI DuQBVXSfVjWZqnBKtLOoYeeoa+bZ5rbRPoDciNMJZ4NJ7aOVkzWKiYn/3LMzZJKyel4mRBEu q7/HkwDLT14qviARlzDU0L8Zed7s5Q+7g/U2+Sa1YogSmhrdkvdtnc5vbJaBwO6S6B5yKPto pLAj39P+JNUCBjnoI+hh7X4k9yHESL534IUCY0B2yEq0qqlHmRO+sNiDaF4WrVQYA//rL+G4 gPK+t4sVkzgPGzxp2cBKBWYb6aiDJXwNb09vjVuTbVnXAIUI01Jg5yWdbQ5WmFdLDM6RA79A OAdzNL76lDnzjRB3gaaPleWqY5KROqx3ag75ZmdpuHlgWMZWEgAhMp3yAHzlbRXq4PK1ULRb /D+Jwm+KJy90nSf/kFIz+KxRFYWMI05RsN4GPrnbzeIVfe4P+x10TF7hx5cvTQIv+RyimveU 9EefvMQM4a1QFYkyHYb726mqSsvLdWXC4/umBCBSIJzgYhvPx5T0v0GfSq0WggWsYSuuievk TlonZG2NMAmOssK9qYz0TBhYst/TX1PeXWL/AgVOA4Uwq8Maf0XcmHiPvO9n4diPebAUJ+Tk mho79/ZBDTUz4PdCMjCOLfR59js8zXxFkJsMXKGzdFI3yhyAEbru1eQiaLvdrLGwXaB2EyDD jv+zYy9Z6vuDPS3WsWQmATAV4Npvv546ugAPc+KFPslarN5crMnh1GOfrDvBGnB0vfQCZXiN PW5xPipuPKIV8Ke3/Vmga4tk0dzYQwPGoI1uNW4DMinJavpQRjzDMpjE4hQaQGmo9/UunO+b Ow6vSOyveb392dPV3d8qshvvMIJkXzuEqDR4ranvVViajmOmuYAF4qah/dIwoJF7GrfaHPXH T6hEY1zffuxH5Wuixgkz1J4QMTXKtnNeO6rcrNJfwOBiFiNThnlL79na0DCLWKI1x8iG0qIL VxM35i3o55F1nLopnptqzAylzbp1gKKgSNtb6lngFEHFf2b0k2shtiZiBKPqfmwIZpBloor0 TdScZXQRQKmdtYQONnGyJzxR0oIL8XDspbQRPZw330dH7oUqcn72CkbJMvHm0wxU+ng9XeEC ZFMOPL5RaDoQ7/ER6ht51X0TxyyExyWmqxhDsP/IJxUBaFn/khI4LmYvu4KCczvnWHX6n+36 uex66EqFRepCcflyCMJuKnIKezQuam1bl6X8Z/exKsEEDhPSC5oYafXySYeGNBHoVAQNO1VZ xprq8AGVKHFmGwSIUiOIucVvSILeccwikPsg1gijYjodOliZjxsal3XhRXx2P1WJ6kdyJXmA jtf+87imMBjYx5rfz6U7fjTrt9hXvNv2fy2kHzPJIzFrlrNQmk2jJUvCnA50rhA0fd8yGJcp 6d9+fF0mfexHXtuZXVDY9k1OyNT975A842D3JPseQTIlldw2x+CNpgUKIzVhGq+bkUfsdr62 2o94t0rnAwFAqVcHP8KVVnQQG+ts92weWU1JHeeCry+QYBShBQwVcZWRJJrPad4rxH8kbz6C UO3IEyoHJVrsz3YwCe72aq0nFJy5J7ia4kip5+Q3lQRWM0Sx01KoQwomt7/XWyB8kuNeG895 9sp+SLoLcqsdopNfsm9L9yAa3XCGPW9fJ83FWZVsQzZqCjdgaIh4rSMJvMPTA9Tv+73r068H 1pChEe+dbOQpU7ZJoRr3hymSjKG915OIUlXd10Lrh+0Esgvf+IcEXkAFsfez0qbHsnH2Slql NwHFegRszQ3d3P/VIjcfsC8ZdnuhJRzwR46GtoOExnPZVzjOwBaUM30qnnBdWaY2G2No54lm pe/mzdhz7Lbegu827rNEDBJ1bAU5QzK4fAnVqM3KVw7GROrouTl2kjJeXp4NIQHpOXgb8gmE BAFBMgMqELf+TSOlr9TO1pn0OaiYBizzxv+DFog1e/Qzn4DbspILSmC7dL6rVS676Bi8gwR1 3ufL1UFxuwUV0Of3sAyvAz8yq6JC8QeVoSL9Pw3IYN9pC+ANiLxJ3a0GtPABrCvMF2OWuZmF azp1N6LDsXbELK65Lz5q6DCbBRGjtkFzVbHIENSlsGaDCDib5KFcfmLbexiV3P113nZymASC L2Fkry+C5RAMbzorcF8A2RI8fvEoePVeGmdf1IWMyjqfZvLPlqeSVyHZvsEilQu8BEy9W0q9 pQR+JhAMQbNJW5P8ntH5tjjXFY/hwa1hGDHMuhseB4mx9BT0DyZBbOd2uWmQGFj6CEY6nLPJ VQf+hAz3BjVsW3qsuAdhtDQV/V9+hiMhmb+Q2ReZb5MnROSdD0LYJJo67ImiSd7lOAG32d5i paWf79+6WVx7oeBthDesr7fNrd7DGoplIPC7kIWO455i/tKF/KvztQVuKWNjxXrx9tU8Bq9n baA+9yfOH1hJbk7OqjAVSEym/t2Ew+JvUlxQpSYVteBfLTdz2YIK//U7+GUJsADOo564OHmN GVEcpIJDNcEZpx0x6fV3Lxj9kJ4342YihcR+kZjXenYwx4hVaRQY8Fx8OOepdmu5uMsguvnM laHa9PtTc35uW0VN3C6aU6q2WG3Yv6DqrAZCdc5Mr5T2tOMiZxulqTk/uioAVHPAOoxGGu6I NFmWLVmall45qhUGhp+21ElFcG1AF/W7edhz/cln9tY/GIyTujhk1yNAVPy4PBMt1+FYkGWU AY1zvl6GDXmZ4yVdFc+lLvbX08JZncty8avOWi138iDc/i7Tc3a2zyeQwrqEpl3Qm/XAsCG1 I517/KO6PwVtz6s6k3vta0RHmVZKt9ZAZEogmIcvhtN7qqYYggn2AEkJAjY5c4I+7zY9re/P 9gGVuKLCnZKCZckBnlV0hkHlFAhBuAe35g2L1tHJdMGc3dqk/r/vMHoct7Nktwkb0ibPVYQ9 AxZZesCqFoMK+KpmYbP0N6ULIlsG3DO3gm3IrgPKY3c1Mo7NTIa735EmhOaZGbUVO5jyPWc7 YCi422sjdxNTDrMN9DO5V3xx47pvPJPzhJatGXyDCHNIx2EdxNT22AxqrmgpvIxrZxb/nBSD FHnPjhyPEv+t7EbJB374rhJ896Cshxe7YKvcl6r9G/NHhAulJ3pDEtAK7nKZfMt1abGgRCaz KjNftReeBjXmKNfErih5AgMFVe52tmHPPkXSX3ZzTbadMflME4Bq48eZlLXKsKfHorLI3xEx TvCGaRaD8uZwD4ghh9dzqrA/JeFHs8jB/4XsMfOoOH1F8i9ReF38yt5OB3uwO09UtCpedVII elBNR5rQoVOqxwwtcPn7Qw+FRYi3Gnvlc+c+XxnjA++ifEA8oOzMdQm2w0JhugQi8UVzsXUt DzJbDjg7E5CJsgpFkFT2NQioikblysY2GuuKiAPxl2FnmP3NtE8uwQuMSuUtj//gzzj5icyB S11WkPZxMrx2r+P4Lgwcl8Iofj+PmJ/vmMSSJBQmuqFzKuTLBzyiP0h3CqSDfzSExHVmTK9A 3TozHVG2Pvky4Ka20y4Jrg0DjPiWlXXXOc5uaM97C0cKCaEZqgElNWSlEK3eKM/6lPbYQE2o qa15fPSyotTpDio9dw7whGuDc6awJGi0mznfA/C5jVeQ1X/qpaR6ncNJo8RNWATC1nmLs5MN 1up8IK95b76F69Z50YnFyIYMCNVarFDTVOTtlK/oJdgvwNQIvvz9bzKE4X7YSKudHfn0xX3A cjm2Xf3gaBiCnjVNt2zzHha/mKAv6fgS/X2x5cB2SM4QhLbzHOLpxD7MOt/pQcsQowKLoN1N fm8RdYbAX0Fh+s9t7dlXKwr04upkWGLJPTOHJLuNUYhWKM7ykWxomz+FZps28ettpaBIQl4t Mw5/atoDaMX0A3U/M3tOyJ1/wvsyz+rdTQOsmyYC/kwTP1KJtD0RfR9X15R42SHZjvhaZu4E kR11b7jnvgH47Axx3UOnnFrfFpXHCanjVEFGz99ee8v4kV+hdWsTg1dI8rmNJ5T32LgrKRkw GLNI+xdRizB1lkVcdYe+W7qp5p95gSY4d6nFORX95GGX4/NDRrlyI/m/XMnslOh4xAtNlqTV seoHeVCCqm+duxrLS/57+a8YEHlfdt8T9JIsMogcnqFou5l/iNcgYlPmM45giEQhrCrxGGu3 WAhOlXKefZXibmz14/lP/VONGOpO5JiMuZr9DDln2QekSdLcm08bfYhOINTULshntfNBkTZl ZvjDnVO1tc0cOI21+7Ub3IZRbOsUzZ7BrcHz3kVe5Tu1RJfNab5pGH2PeDb/r4vuK3lsjur/ g49p9qTneVif8SbNkux8deKi4ZMLm3BVPUVnJpmE4BlspeMmgW9W0gframcMJO22PcKOvuFH in2+omv2mWAuK9PZUpRZYjF8+Xq8bYjxnxzB1iAD6eNZZGA55BuyXg6Pa6TobpfyYAaxbRVv AI0S1H282CaCWxq/TTJAjcyoiWjVFd4keFUQ9qfs1SXMdgnDavPY4rPl3PQfHu3b4jZEMBKG SjxHDLu3u05KRZRx3KpouSN7QstO+lLQe55XZBip8yH8fnIgonpcEpffzViuCaEaCdt6e1zI vt9QHUKsTrnocvR5xqK25Evo14Idj+8cYyu/sObtV4dwR+hsUZnM2BJFE6fntHpq2QNYK0Pb Eb22xELbKltcqkft2szdf9t+iZYDRve1z/oZiT28k8qP0akW/QdeXmU770DUB9k5MUQ0RlD1 aKeMfYpBIu7HGRa6DIIzGmJCKsmYl7nlcEh/QrG5Edaq+PDSZEa69yTb6VCbGwHSDJA+9C+D d+LztozXU7xbn6ZyujD0Go3YyZv1i8H+KGlBfK/TKpdZfB/GP/r5Vv6j/gRaYnF5R2SQMwwI I/YkgZZWpHiYB3F0KlxbwLpSKXKuRfi9ltgu7PIW5NYIxC0PEitkkh7G+zdEPiMFnDF/+ZQF hENxy4yfmeEzVCnBXIqVObYpYK25tGV9OmQopgkI85um2+vlM5HrGq7pW7fOD/bcepBTo/8W RPXyvEzQjc6re1QnztRGd5UeA914bOi1p0pwUhP1YjbcLckuvqGZ697Fs1geVLnkyj1evvr8 +Y7QpnEQknIEw4z9Z1jlf5/9+sByOCZHk7AoqCQrhCuL147Q3roaXeLDS9XJ/I0MgpEtpyhN sup0d44E/4oEORdNEMXLRw6+Of4/08N6aEeilG9lihbTY9g3l4WzqZh7hGurDMy1M+k0YlFa I8wys7PIfPYTNqvFneU+X1lywdBWPh0FaHpAcFM9A4Lo/Umktcbge20jGdxvJyfKi2g2ZBGU WT5wPcH6mnxeSF7Upf0jbyOoka8Z2QSSvP1+eH89E0C5dST+aVk6yk8qCIbpyZdLvlwTl/uM frc1TdYjLH7xyygWNMrqcHZlQ55MYWMPvmbRFiDS6HmPmn7KbEQpTDDK9RoBFI4pKVEL+u3H US+oi3W6LV+8JAVmaOvP9Gdy57p7p3u4B0lYHTvp7OFIW6Axb4USTg5XK/52fNdNdACjHQYS 1pURv3fHaZPUUoiebmJu9kKsIexvvWRrsx70WyMU8Hhkq+nrZmll/jraCH7mUWT211+I+0t/ kmuHVGJbAYry8nMr+VM1kdQjXWO++QRzMLa21lN1XFLWaZGeZZNUhFu7b65W4ZT7ESs4aKAQ DzlwifhjFK01fhCeoZovhN1a9EzTp9RH/eJwpgSLc1nfp0ApodwsTxpk4qZE6CgMT53NsITe INlct9xxXPHZ+HkS8rmgiw75iukDoN7bV40T7g8SIMjSmjtLSqTXKrrADf5H60bo/YLTMtVz cA1XAgH4hli3xiSexehcAx8plePhQM34OdraDGABWGZwHF1d40fKrBiAnfHB0KsuhRwAKdVy EdV2q0f+F1rIbLl5ULSuwR+pn19OlAb2o1UcyBmyan/Olwt2i5jwT03TwUhLKFtq69G6zywp y/K0soxu08ctrYWorTGxD4mZw3FoHf5LCyoGjLzCXsiYjfI6O+T/J75p38TMx83pXjOmVroO bu1/o4DBNyUGlXb7COA9ii4Dz65AfUWPgxip3dqUOdnR6igw45TRrI3JbARH4uRIf9QCTnXD 9YQsMJBKT2i0NRsdBPzTeH80+3e/6mEL3FxVYjHpGhsMJ597x8uo+AEC8hK2KK/L9zGg6rFx KO4bz39KKiqokmNHnorRrq1v3sTOt/F76w+nzYcYaImRafBmtXGVR2NU+05aHtcJOqwgXmW4 2sKHbKOSaZgOAfDDHpaIj59wj/i25EvgDeTJJS/kpy+u3ejoW+gnQrrDdpO1Y2Dur/J5ko4Q GzLYZOht0B3cjxosGNSGZo+cl1WasmuFqIs8hHFZg1f6+N4n11sgvSzyUcObEFQHz5c1c8xX lLPxLTYx6mmC0/Sqv39xN5AdXntMVj5752z7B8j/5cyxM8mavEQprkLY0dn4li7llm3iqoQk yjq0nd8pTdx5+xBXVgmU8Rv7n5ftHY/Zo42T7L6Lxh0rwxlHuQB/FQtmdcl1TM8gd0sYxO0r LuotBlFWJFntEvA8SEyhH9C+WzovbXOhDsPaDlOaerMcI8GJhq3u9fZjEXHrvl8wkAtBPX7F n0OdUaxAa9pD/zTQFxd0yKsGPI35o2TNxG6ljWYgpR3c113n7HIPVC3LFmcARvz1LKIwZjFX +M88HMuKX4X3KdXY85AiMj3Gbur/6POkerqVduGk6Vt+RHP9azD2o0cgk7gQCNXLzT1aTDcc CdJ7DFsBv00sEKV4tdgkwH6SuHwxbA0guTv6QYLdSzpH3htK+9QrEpTnZFiVJJHh6n9X/Pb6 9kbRC/NdXHdDUv3gCsifX/o8w3K0k8hF4ITFLGESxtPGQA7SduKGU3wvjiEStJfiolTDwhK3 g1Yzvmm06QOSWEBS6n89O3guKFclTzdNH2WvXw44+VZeMCBhD6PtoJGj4AAcYvmA0ZC8ygXd 5u+kyKm0rFkUfOvTm/WKkBqzUMBBKn9vehmcUYnEz11U5m1N8vNBu2Cnv+poc48sYrOsMNbO uJhS35kMOCZN8zxz7LUKMuXtgWk1i2XcHv3hPkOeh47xPrGexBOBg0r/a5wSumyG5r6ywQJY pwrAuT1AY3j8PNti6BrunUB9wwXYO1bq53q2LQw/jBecw1SorPP6eC8RpIw5w5/FmiOH8+eE spDm1ay3E9f1DuG8tDV1uKbNthe3NyPVWIXAf/vB3Rd0siEK+H1/68Azp+nA9D2GnsNUi/TU diNpcvlWJDHOrn740Ne7UWniftpIMfZM6QQ9ABBgH1i4PjJC7pYbZJJWANYbmavaPczK5voE JQQZOtO23r9qpg8Z3JJQnFlXny1T0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYOjtEAAA w4OYh1AsWASBfNu23zg0MCyiYfnObQwdEzMEAIbI7/DD74/KCK/bk8z6dvIe6qN4g6/zpT+e 0+Pj05sw9pOTo/L4b4JJ024Wy3RT88IXk6OkAl7is+Fv4JOijiz8mBa+vpDx5m/qurwc0tKi PH2lpHfVd19LLXzCXmWpvuFi1CZNapZERiYcwh58k+GCVvyJll9t5mHQ12ZNqJh+YyTjQmjH ljg3MEXoujavasPVYNvx6YQ8yVhfWJdct4K8OX9hszzYv7o/uy8mu0H/zfXXEyOPvVuFvABY rQX8JszkBIprIIteQKqOjRmXz1kGyTt8TF8E2POVUP8HB1QXFBdFTiPl8pLZT9BQ2lo5pNgb 4Uo7UR/sWxvQiUxdC/eY4jMvWuI1Nt4O2nlD9A9QdeWTCF7G0LrYuFRZKqhPQ+7Kv1JQ3pwM mVPfrzZIem43TLqKvZeB28NNwCmCp2kyn8Xs3GfDquWzCCCDblQ1R/SA7Li8jaDxrWc3EYUA EAlMkkfbr+3dFz6u5kkHUmN8uLLsFCl3CPaqGieP1VXyGavzz9UAKpZ+veSHOTC8hkgWyl9Y OyVNzhTdoqaQJ7IuUYrBN7/RBvr9Q1zqhWL3IJI3RTo6FbWF7fzhRreFR4qcGJHOYX7M2szv fr3Ndp9CB2V3oQeKDIi5T50JPEGWIGMO9YKIgqbJy2hp5Mj0jCoAG9x89uocGF32q5QPD6aH rqzTmJZlY+g96XCNykElP6WM3zI5C7wbLuzd9rU5NfJans3kJz2fZVOF2SwLdlgj2dk8uBy8 RXkXwrn6xgiokcfpFIqsNrUN/Xuf7+6FDEpw9cPNYR9U/jjIQwQgzFBsap/Z/DaoV0W2Fera 8I/Hi2E4Y0hpuqzGewSwYWA2zSEUSOGvDbofaFQwG5c5zHDwKr0zT4mPi22I9CZG8xBBVEDf CZqizK55YArw3khyVFvWOkDvJyHtc7LN011FmjJ0X/zBKcf78+do6AvQeJ+kAYh3dzPgYpP/ Ts7Yukim61hS45f5PodE/qbQSR6dMt0zb7hz9bb3RhMURK2Kp828L8o4gJZFgO9Z4e12AO+t I/BTizJrmsQejId+NEsBm5Sol2gX5eKd5N7hs94RvF3e1FKHDziXH3UyFkaPFfTklRpEGy4V wtGAwK5qMtv6cQeZbWHGLPjfBmeSGEJHahU+PTJJJ6hNKgKnr/VjuATLVO/IPMlNh1ZTV574 c39R04xU4sIvB9qWi/8fYVVWNiEkj5B2UYxWNWo5lLCTZvSVtZVNGqlWVdhOmM0TvFGbee08 den9yM9X+goD2JMHOjujd3XfTCtWrrfJ6tWG8OYgtn4jGTmfgQb6pHz78CT6ERFy8Rv6u2Eg ibqBhBQUQ+HYpBdh8FrIz8bvGuiWpnvjkuCnUGs09ds0H6/bsdVoBHEYEE5DPIwMsp5CLwE7 T7+sxvyZDLRkWAjgzNrrCnt0U9asb75Y7BwG8KTmqF2DDNqnRAOPG06d07TUN0k4mKo/kCaG lyF33iyVJdVV5gCxQTL42Ulhzcgs0N9mZO+/L7980mDYIVLPpyIjYERU+0QZV8KSo++vUP4c DnZGR1BjUbypBlPuD32BhGVjcl7U6903bpt5EHcRtkBm7ttrbXXpLgbg1L3zOAZWCmfbbR8e Bva4FACsWGb461ZCtTNC08IXbEDrtNiZ8eeAIXPwTVj3gmazYCM5JA5RNoApX1weFJlenl8e CyLYn17A+AJAXWsPNw52W5C59OtBhCklACirKLgPYbpASpkkX8zJ6qLJVbgqDuzzGGhjizEz k6SNPIRZ5WzcJB8mJaHaYSMlKpBkDknwNE6lLpBh/l/3ayV7cB45Zp13iak7WO0JLsSP+WIT DdIXBvMWPITquymyGM1NO1lO9g4u5suTzVAyPyKm7VLL0I1IyNF7yDH2rPz3p48mW2DxLz8f W3u/1vw86gPjuFw1Wr9bUcEiiIVOZYq99YLB0ry4bd8DMPgRhO23LhNGm8pU+WaX0aL5tPbw 0yEQTWyb8HJzKvPmNU9aY6LUdif7DV0svfV+0doQW/ngI7JwCRDbWL/JbQL8xy2ukNN+tDeM RD5xVRPZwzcpzgSrb/+AnYR+97Mpaufszliegnm7UpAO1fLPxoUk23tyarukb7rz6BHB+uI8 gtbQzwFOvpmtBGiBG0tYpqdz1qvbGuf2Yy1tyyMVv1OHzWO3xWXcTUg0PeJC9hpWajQ4FEgQ NgJo80HOp3Kxz1I9e0aHGkZMpilbuhZCblpuEFVcVEi3YDsFVnxFUW+5W188t3NJEFlWAjeN +32Iyq/j9rKvahTxYbXT62+MxzT5Y24HoPlrk9z7LI8aYEbvNZMQQv0Vr8Es+eg629UZD6T2 2h+YrzdrcCQc/NKpbGDpwi2njGl4UFFy4NEWF97cUxc7vaDK7hKbEkSQKZvu65MUHHWHauOo h63HTPHck0o/rmSb6GvwDQNi9hVQn2qRaNzgwwJ490LKw6z9eW//FkgiFzU2ZAcj53QD6WFg RztVI9GTIDSubKHFQo/SfGve0j42B4dqJ8iV0FMqx4d1BlpdTHDzaRGfcZmSt8Lj2GjLXG4S yzt/KD1YX4nfFvAnn5K026QcKxkGa82bz9CcUmSLMrbMEUjvQjaZTp2SpLZOryLh3zDYlgFm xs5n6jpTVH6gkUscvlLwiTSggW/sE9r+txIp8TtVZkm5+WlysLnzbquIZZP50/hrr5ew8QJG ES7g5lSyUqKgBnzHfvSHJRMvplvSHo8hk95lYdBZcEyAoGR52oVd4s5N8TavgBKzpWHT77rM t6jpyxce81715EfZ1cpcemqgAZPDDyOVj8GDLGqPOk7Zk59v7oTRi8CoHfsbjz+IkwRhYywS f6U3cpMIqsq1TFpDOxKhNM7o2CjEesW3v7JSdwoFKhbGtKMqJj+uCYAKGCv4AQZIKdH8nSx7 vBWF9XryYkrfEa2p+tB/FI3beLN0Ih0R9VvvXKh6iXkbWOToMxpav410StKlriwdiMKt8PKY S5c10ze9MZumHLrgRsd83729fiZsNunUGH17Q0efMMdhFC7dFPaPyZ0ts/Vonblf3CqkEFag Xpgpla1jO8lFox/CmsG6/bCW24QcldIzq+y0I1DEA1+DYFZtMcHVfAZU1n3kSVjqrxvZn8Dp h4K4JtMmrqn0vABfJ03T2WMteJEqABrNiTEodOW7Px+JDDW2WapGPFZnkKDSLCw7MjMahzYO gFrBwwtByHDsDd8hkvarKqkxNw55Zvsz1F5iT+o0qBx40YV38MPOE4iRtieQMjdEHA9QKvq+ DSHZ8/nT33des8zTQVY5VNeTe+8kwaaACP4XjFhhn2KEkyRD74ObQaHCkzkD8Ka1o0C904Np 3GQjZvFNTkabd+Y0/0CbQfeTl3Kn/CE1NsLo/O22fG68uE5uPvlhFmuZ+CqPgkXm9Lx58ZPg d856nZmf2oRSlgyemk7dwT6bwR/Y8dwIHgrkUF5wWQBjI1kWeZ7CucM5BcqJqlKmblnk2keZ xMCawMacp0TqyU0XUvKEfZztJsTI+986VOpuh8PmgbVwSZfKFVN0MPLQ/4c7/t1hrXJIv6eo c51AMm/h7AvlyFnUZr976tXdm90/yWcDyn/K+5PdmJklEcuS9fRQsZ5dESV5FmV4/jEeycQe JDR8TMxmjkGWCPYz3nk3bpa+bBNTiGPw8NfW1gzmpW4i7oLw3K/gx8Y7wXFX+tq0xaYF/dWk M/uCtDJBSjHpLDXB39+by0n4wl//cZjEgABTkdm53Ri2buD0+vAGTICAaQfNMdkRuyjDM9i0 81p1eUbadhWYsGFPIdZr4HpYJcAgQ6AlOosZuzkBrKkcd3sb0h6LhY22Fx7fqPaGKKXcUeNf W6+IFVMWsl03+Dv+PXRLIZrVwjtCqev4OnxTdlA7Elmyb4kvB4xUp7XA0OKO1cgc8QXgRMxh BfwYlmzhwbmcYtx8/UFEW7k6Wc7+Wo3V+oON7wSDuSBfFEJ4snQjuk0B1U2k3XWNxEZpMrDc wf2Am60aPaAEgfHJQBNYy1zD7/4yTaavAIepQsx+Yoq+t+nWk28+CbnidxK7G+ApjQhP8oPU OV5XyMZvCxKWZxFn8/5bIBrL5G6WXBpP7RSne84da3357CPEdGIqBJMkoay5qoke+vFnSFnw 7gziuW5HIemMHFUWzGncVv2RKGd12WrbfcgxH7Y68GBjM0Kup0BY1xzKRJN/wya5zJSyMrab jCAmOTJ8nOwmo5rc/2oRWSKHwwbRbJmh5BKAcwytskhJCjDuPjiZUgpHJyAIGp2DNXqBxGqh sTVfSYTnnKvbJ+B4kC31U+md3yyvwHyWwN3ylx5y8KDMzX/mBtgCQdqBKeUENUUe2uQm1Ew6 4OJK9wDsnaGWlq+hIdx8d6Szf1VAj55wxmlUFmxg/NKmGU5papee+PT/mNbw3an1fyDKcmOd CvEMoo51h3XIaMydVHipKR6ZOmeRYpbv/6/6Aw7nUv2HwQM9tKyfYStfmjRtudF4vg4l98Vu eka3eWkG9NrmQ0BpbfTJL8mCYTvbiYxBOUAK1jCjMm3fsDwDQFeLLaq79pQwiivA/xwVQSxs oeQf5yFjQizME3fIHEYvzTSd3tShuq4pDstFyJSCZyI55h7+MddaMYxXli1pUEcYV/AIUIgL Zn0aWw8+8nd4Q6dsq0Z2OkU4CggJ0P4fKozTcrR6jhywQOljFE/tn/YrqRmkz74SEi5epR5n l6IXav9VseChRSX2Wkc881hb0PDBBVKBxbFopOxZvzS7tjJYrohYmjBqe5jQ5wEGU/cf6tkI Qsaw4dIoGdQX8JCqtY+Ota71qXEWyN4OBx/BlrywUOwev8zx2RNDl4XHSm23TNboqIjYqyDO 8Zn+RA9uQGerCdJZ//Wzk61KJbDz3ljrFlbTuBSLx8zBHsE5DLc8tNmGRhjT5S0HiETL92vW 2G7QV63u6sAHiWwuLNmleMt2itsp+ZlWR6E90PlIZndmthDhT6mikBS5Q1TbUVgdRHTjSg5z xIDnsBK6SpHOHAyDinqeIdOxthjeynkkdv/jZ6qpPfSFjU8a0h0ZoOc7nS/xEiupYKFDrDUv jLLo13hGoP2Tcorl1XiVMuahLcvrAs0gC8foCAAAADPH6QcAAACQC8HD+DPGLVPdPQ/oYAAA AGXYV0lrKPAZBIbpZ/GZNp/580cJZfOzZttgYDbZ5g8D3f5U/f4VyxgZqpZ/ykr+7DpYz1Lb MzFmEnt1BOl5CGqvvpsAFlTeB44A+3pvJSy8u7ir8G82ZnsH4GcI2iUEAvhzAg+IQGDoBgAA AItkJAjrDDPbZP8zZIkj9/Pr6PhzAg8h+Sv2ZI8GXugAAAAA6wLNIBPG/IsMJFiB6S0LQQDr AWb1A8BoAMP9AF+B957JvADrAXAD+TP2gfYDAp0BgcYV/mL+6wP/6/8DwZAr0oHycsoDn/ly AQxr0hcxF8HCA/mD0jmBwqHYN2PrAWb8K8K4BAAAAAP46wLNILjO+XAD6wP/6/8zxvjoCwAA AKksfFGE6QkAAAD5i8fDHW0yMxOD7gHrAXAlILtpSegKAAAA6QwAAAA9FENqbUADxMPB0En1 UYvO4wNZ645Z+HMCD4hh6wFwQDPCw6Vr60V2hr+HpenZmj+Fj0v0s79Wb+uxvFaV6WMy0PR4 gnSnilH1aGqW0Xu2nG4Zaz/p2ZsJ30WC+B3CIgr3y/hLrWuhWlIgdrb8plVvjbqbke5yhu8F o2g6OR20aJCACmve/egAAAAAgSwk5AEAAP9kJAS1xwAAAAAAAAAAAAAATIEBAAAAAAAAAAAA nIEBAHSBAQBsgQEAAAAAAAAAAACpgQEAlIEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAtIEBAMWB AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYgQEAAAAAALSBAQDFgQEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA2IEBAAAAAABLRVJORUwzMi5ETEwAVVNFUjMyLkRMTAAAAEdldFByb2NB ZGRyZXNzAAAAR2V0TW9kdWxlSGFuZGxlQQAAAE1lc3NhZ2VCb3hBAAAAAAAAAAgAAAAAAOKC AQDpggEA+IIBAAAAAAAAAAAAGGUAAAAAAAAAYAEAAHABAAAAAAAAAEAAAKD+/wAAAAAAAAAA AAAAAF4OzhaCMXhSMC/bX5A63VHS9XHghRCKC8xzlHoEm6N23ai1kFu9Ee+EGe0mE48xd0G5 YczZBpucqqUyzjNvNeSyI6JRYZvGzCySzUczJxC2mvN8Q4yp4Ez1d3yOPechMisNfH3PcOTc tRbwYbetc9zTbNzIz8pPgSzmsW8Eg7l3CeMb2zQAS7m3j8QSTIJ7bCwkCUvbEaYiAAAAAEfx jeoAAAAAAAAAAAAAAAAAAAAAAAAAAMpzF8NJGXOkvMk2wz2BIupwWQi5knqyioK273VCIoIi 6lUg729dF8bTtlyoabuye3dolf2B2p9yRy46AAcBOi4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0005_00004E52.00000A47-- From jhutz@cmu.edu Mon Mar 8 21:15:49 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 08 Mar 2004 16:15:49 -0500 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> <20040304230725.GA19887@internet2.edu> Message-ID: <5280000.1078780549@mariner.pc.cs.cmu.edu> On Thursday, March 04, 2004 18:17:42 -0500 Derrick J Brashear wrote: > Not that easy. Same issue as the cache has with reiser, IIRC. look in the > archives about 2 years ago. Actually, it's even worse than that. reiserfs _has_ inodes; they just can't do the open-by-inode-number operation that we need. tmpfs doesn't have inodes at all -- it's all dentries, and the only way to find them is by path traversal. From mfedyk@matchmail.com Thu Mar 4 03:46:48 2004 From: mfedyk@matchmail.com (Mike Fedyk) Date: Wed, 03 Mar 2004 19:46:48 -0800 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304014303.M64769@soltis.cc> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> Message-ID: <4046A6A8.2000609@matchmail.com> jds wrote: > Hi Ryan: > > Thanks for your help, the client openafs working again. > > loop: loaded (max 8 devices) > Journalled Block Device driver loaded > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal > EXT3-fs: mounted filesystem with ordered data mode. No, if you're going to be stacking filesystems, use ext2, not ext3. You will get better performance, and there's no use in having two levels of journaling in this case. Mike From mfedyk@matchmail.com Thu Mar 4 19:20:26 2004 From: mfedyk@matchmail.com (Mike Fedyk) Date: Thu, 04 Mar 2004 11:20:26 -0800 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040304151349.GA30594@marvin.deek.org> References: <20040304005117.M99283@soltis.cc> <20040304005913.M1858@soltis.cc> <20040304002804.GA5722@dbz.icequake.net> <20040304014303.M64769@soltis.cc> <4046A6A8.2000609@matchmail.com> <20040304071846.GB324@dbz.icequake.net> <20040304151349.GA30594@marvin.deek.org> Message-ID: <4047817A.7050707@matchmail.com> Pete Walters wrote: > Are there known problems with having your cache on an ext3 partition > instead of ext2? No, it'll just be slower, and put more load on your disks. From jjneely@pams.ncsu.edu Fri Mar 5 18:04:27 2004 From: jjneely@pams.ncsu.edu (Jack Neely) Date: Fri, 5 Mar 2004 13:04:27 -0500 Subject: [OpenAFS] Linux 2.6 In-Reply-To: <20040305174541.CE6E0294CB@smtpauth.easystreet.com> References: <20040305174541.CE6E0294CB@smtpauth.easystreet.com> Message-ID: <20040305180427.GP7314@anduril.pams.ncsu.edu> On Fri, Mar 05, 2004 at 09:45:41AM -0800, ted creedon wrote: > Can someone send me a list of what needs to be done to support AFS in 2.6? > > Tedc > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > There has been much discussion about a week ago about this. Check the archives. Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From kim.kimball@jpl.nasa.gov Mon Mar 8 17:55:51 2004 From: kim.kimball@jpl.nasa.gov (Kim (Dexter) Kimball) Date: Mon, 8 Mar 2004 10:55:51 -0700 Subject: [OpenAFS] translation help? Message-ID: Spoke with Giuseppe earlier today. He confirms that he'd be glad to do the Italian translation. I also have a Romanian friend -- native speaker of Romanian, near-native speaker of English, if Romanian is of any interest. I'll try to think of others. I used to teach English as a Second Language -- these two were in my classes. (I tried to kick 'em both out -- their English was excellent when they arrived -- lazy bums :) Kim On 3/5/2004 6:34:46 PM, Jeffrey Altman (jaltman@columbia.edu) wrote: > Yes, I will definitely need this assistance in the near future. > Thanks for the offer. > > - Jeff > > > Kim (Dexter) Kimball wrote: > > >Hi Jeffrey From warlord@MIT.EDU Mon Mar 8 22:55:46 2004 From: warlord@MIT.EDU (Derek Atkins) Date: Mon, 08 Mar 2004 17:55:46 -0500 Subject: [OpenAFS] problem using kpasswd In-Reply-To: <1077894067.10865.20.camel@localhost.localdomain> (Frode Nilsen's message of "Fri, 27 Feb 2004 16:01:07 +0100") References: <1077894067.10865.20.camel@localhost.localdomain> Message-ID: Looks like you're using the MIT Krb5 kpasswd and not AFS kpasswd. -derek Frode Nilsen writes: > Hi, > > when using the kpasswd command to change users password we get the > following message: > > $ kpasswd > kpasswd: No credentials cache found getting principal from ccache > $ > > What is the problem and how can we fix it? > > > -- > Frode Nilsen > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From warlord@MIT.EDU Mon Mar 8 22:56:26 2004 From: warlord@MIT.EDU (Derek Atkins) Date: Mon, 08 Mar 2004 17:56:26 -0500 Subject: [OpenAFS] AFS on win4lin kernel In-Reply-To: <50825.151.201.9.92.1078083772.squirrel@webmail.cs.pitt.edu> (artward@cs.pitt.edu's message of "Sun, 29 Feb 2004 14:42:52 -0500 (EST)") References: <50825.151.201.9.92.1078083772.squirrel@webmail.cs.pitt.edu> Message-ID: install openafs-kernel-source make sure you have a kernel-source tree for the win4lin kernel! -derek artward@cs.pitt.edu writes: > All: > > I had AFS running beautifully with the stock Red Hat 9 kernel. > > Then, like an idiot, I installed a win4lin patched kernel, 2.4.20-30.9 , > and now I can't install AFS any more. Installing the old RPM's didn't > work, and when I tried to build the source RPM > "openafs-1.2.11-rh9.0.1.src.rpm", the build failed complaining about > "krb." (Installing "openafs-krb5-1.2.11-rh9.0.1.i386.rpm" didn't change > this) > > So, my question is: has anybody gotten AFS working on this win4lin patched > kernel? Where should I go? What should I do? > > Thanks > > Art > PS: if you reply to the list, please reply directly to me too....thanks :) > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From tcreedon@easystreet.com Mon Mar 8 22:57:13 2004 From: tcreedon@easystreet.com (ted creedon) Date: Mon, 8 Mar 2004 14:57:13 -0800 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <4046A6A8.2000609@matchmail.com> Message-ID: <20040308225716.DF520B087@smtpauth.easystreet.com> Bring a sleeping bag if you're booting a 250 GB system under ext2 tedc -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Mike Fedyk Sent: Wednesday, March 03, 2004 7:47 PM To: jds Cc: Ryan Underwood; reiserfs-list@namesys.com; openafs-info@openafs.org Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl jds wrote: > Hi Ryan: > > Thanks for your help, the client openafs working again. > > loop: loaded (max 8 devices) > Journalled Block Device driver loaded > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal > EXT3-fs: mounted filesystem with ordered data mode. No, if you're going to be stacking filesystems, use ext2, not ext3. You will get better performance, and there's no use in having two levels of journaling in this case. Mike _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From dhk@ccre.com Tue Mar 9 00:15:38 2004 From: dhk@ccre.com (Kim (Dexter) Kimball) Date: Mon, 8 Mar 2004 17:15:38 -0700 Subject: [OpenAFS] problem using kpasswd In-Reply-To: Message-ID: In other words, fix the search path so that AFS kpasswd is found first -- prepend the directory containing the AFS binaries to $PATH Kim -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]On Behalf Of Derek Atkins Sent: Monday, March 08, 2004 3:56 PM To: Frode Nilsen Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] problem using kpasswd Looks like you're using the MIT Krb5 kpasswd and not AFS kpasswd. -derek Frode Nilsen writes: > Hi, > > when using the kpasswd command to change users password we get the > following message: > > $ kpasswd > kpasswd: No credentials cache found getting principal from ccache > $ > > What is the problem and how can we fix it? > > > -- > Frode Nilsen > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From warlord@MIT.EDU Tue Mar 9 01:04:05 2004 From: warlord@MIT.EDU (Derek Atkins) Date: Mon, 08 Mar 2004 20:04:05 -0500 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040308225716.DF520B087@smtpauth.easystreet.com> (ted creedon's message of "Mon, 8 Mar 2004 14:57:13 -0800") References: <20040308225716.DF520B087@smtpauth.easystreet.com> Message-ID: "ted creedon" writes: > Bring a sleeping bag if you're booting a 250 GB system under ext2 Only if it crashed. A clean shutdown will start up just as quickly on ext2 as it will on ext3. Regardless, nobody is suggesting ext2 for anything other than an AFS Cache, and NOBODY is suggesting a 250GB AFS Cache! Eep! > tedc -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From tcreedon@easystreet.com Tue Mar 9 01:09:36 2004 From: tcreedon@easystreet.com (ted creedon) Date: Mon, 8 Mar 2004 17:09:36 -0800 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: Message-ID: <20040309010939.8EE1CB087@smtpauth.easystreet.com> I stand corrected, good input. -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Monday, March 08, 2004 5:04 PM To: ted creedon Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl "ted creedon" writes: > Bring a sleeping bag if you're booting a 250 GB system under ext2 Only if it crashed. A clean shutdown will start up just as quickly on ext2 as it will on ext3. Regardless, nobody is suggesting ext2 for anything other than an AFS Cache, and NOBODY is suggesting a 250GB AFS Cache! Eep! > tedc -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From openafs@gnosys.biz Tue Mar 9 04:29:16 2004 From: openafs@gnosys.biz (Kevin) Date: Mon, 8 Mar 2004 23:29:16 -0500 Subject: [OpenAFS] chown'ing and chgrp'ing user volume mount points Message-ID: <200403082329.16368.openafs@gnosys.biz> Quick question if I could (sorry if it's a dumb one): AFS UIDs are positive integers, right, and AFS GIDs are negative integers? The guidance in the docs on creating new users with pts createuser and so forth has you chown the newly created mount point to the newly created AFS UID. However, there's nothing on chgrp'ing that same mount point to be that of the main group that the new AFS user belongs to. Should there be something along those lines? And if so, how does one do it? chgrp seems to check the local /etc/group file for defined groups (and fails when it's not there), and furthermore, trying to pass an argument that begins with a hyphen to the chgrp command is not straightforward to me: chgrp -500 /afs/.folkvang.org/usr/user1 Doesn't fly. I even tried escaping the hyphen with a \- and '-' and "-" but still no go. How do I do this? TIA. -Kevin From rra@stanford.edu Tue Mar 9 04:56:44 2004 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Mar 2004 20:56:44 -0800 Subject: [OpenAFS] chown'ing and chgrp'ing user volume mount points In-Reply-To: <200403082329.16368.openafs@gnosys.biz> (Kevin's message of "Mon, 8 Mar 2004 23:29:16 -0500") References: <200403082329.16368.openafs@gnosys.biz> Message-ID: <87llmaobxv.fsf@windlord.stanford.edu> Kevin writes: > Quick question if I could (sorry if it's a dumb one): > AFS UIDs are positive integers, right, and AFS GIDs are negative > integers? AFS doesn't have GIDs. AFS doesn't do anything at all with the GID in the sense that you're thinking of, and the GID is meaningless in AFS except for setgid programs. PTS groups are a completely different entity entirely, and have nothing to do with file ownership. You can set the GID of files and directories in AFS to anything that you find convenient. It should not be negative and shouldn't have anything to do with PTS groups. To grant a PTS group access to a directory, add it to the ACL using fs. -- Russ Allbery (rra@stanford.edu) From shadow@dementia.org Tue Mar 9 05:11:45 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Tue, 9 Mar 2004 00:11:45 -0500 (EST) Subject: [OpenAFS] chown'ing and chgrp'ing user volume mount points In-Reply-To: <87llmaobxv.fsf@windlord.stanford.edu> References: <200403082329.16368.openafs@gnosys.biz> <87llmaobxv.fsf@windlord.stanford.edu> Message-ID: On Mon, 8 Mar 2004, Russ Allbery wrote: > > AFS UIDs are positive integers, right, and AFS GIDs are negative > > integers? > > AFS doesn't have GIDs. AFS doesn't do anything at all with the GID in the > sense that you're thinking of, and the GID is meaningless in AFS except > for setgid programs. > > PTS groups are a completely different entity entirely, and have nothing to > do with file ownership. dirty little secret. the uid owning the top level directory (inode) of a volume gets implicit admin rights. everyone knows that. but if you hack your kernel to allow a negative number to be passed in, a pts group can have those implicit rights. From jaltman@columbia.edu Tue Mar 9 05:09:42 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Tue, 09 Mar 2004 00:09:42 -0500 Subject: [OpenAFS] afsrpc_c.c error on win build In-Reply-To: References: Message-ID: <404D5196.40402@columbia.edu> I'm sorry, you have not provided enough information. Which release of OpenAFS are you attempting the build? Only the 1.3.5x releases are supported for VS.NET 2003 and only when you configure the ntbuild.bat file to use the 1310 compiler. Jeffrey Altman bj rui wrote: > `nmake /f ntmakefile install` fails with arsrpc_c.c error "You need a > windows 2000 or later..." > > looking at the code, i see that error under "#if > !(TARGET_IS_NT50_OR_LATER)" > which looks to be set in rpcndr.h in my sdk: > > #if(0x500 <= _WIN32_WINNT) > #define TARGET_IS_NT50_OR_LATER 1 > #else > #define TARGET_IS_NT50_OR_LATER 0 > > i'm building this on a win2003 server with visual studio .net 2003. > is that a problem? > > _________________________________________________________________ > Store more e-mails with MSN Hotmail Extra Storage – 4 plans to choose > from! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/ > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From rra@stanford.edu Tue Mar 9 05:22:14 2004 From: rra@stanford.edu (Russ Allbery) Date: Mon, 08 Mar 2004 21:22:14 -0800 Subject: [OpenAFS] chown'ing and chgrp'ing user volume mount points In-Reply-To: (Derrick J. Brashear's message of "Tue, 9 Mar 2004 00:11:45 -0500 (EST)") References: <200403082329.16368.openafs@gnosys.biz> <87llmaobxv.fsf@windlord.stanford.edu> Message-ID: <87d67moard.fsf@windlord.stanford.edu> Derrick J Brashear writes: > On Mon, 8 Mar 2004, Russ Allbery wrote: >> PTS groups are a completely different entity entirely, and have nothing to >> do with file ownership. > dirty little secret. the uid owning the top level directory (inode) of a > volume gets implicit admin rights. everyone knows that. but if you hack > your kernel to allow a negative number to be passed in, a pts group can > have those implicit rights. That *is* evil. Does it have to be a literal negative number and not just (unsigned long) -1? -- Russ Allbery (rra@stanford.edu) From shadow@dementia.org Tue Mar 9 05:25:02 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Tue, 9 Mar 2004 00:25:02 -0500 (EST) Subject: [OpenAFS] chown'ing and chgrp'ing user volume mount points In-Reply-To: <87d67moard.fsf@windlord.stanford.edu> References: <200403082329.16368.openafs@gnosys.biz> <87llmaobxv.fsf@windlord.stanford.edu> <87d67moard.fsf@windlord.stanford.edu> Message-ID: On Mon, 8 Mar 2004, Russ Allbery wrote: > Derrick J Brashear writes: > > On Mon, 8 Mar 2004, Russ Allbery wrote: > > >> PTS groups are a completely different entity entirely, and have nothing to > >> do with file ownership. > > > dirty little secret. the uid owning the top level directory (inode) of a > > volume gets implicit admin rights. everyone knows that. but if you hack > > your kernel to allow a negative number to be passed in, a pts group can > > have those implicit rights. > > That *is* evil. Does it have to be a literal negative number and not just > (unsigned long) -1? well, i assume the kernel only allows a 31 bit number to be passed in... From cmom0020@endrino.cnice.mecd.es Tue Mar 9 07:24:04 2004 From: cmom0020@endrino.cnice.mecd.es (Carlos J. Montero Mendoza) Date: Tue, 9 Mar 2004 08:24:04 +0100 Subject: [OpenAFS] Accessing to data with afs client Message-ID: <002b01c405a7$810f5700$8c7b35c3@telematica.local> This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C405AF.E248BD10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all,=20 I=B4ve started to use openafs sometime ago, and I have a question. = It=B4s possible you can help me. In my cell I have the volumes root.afs = mounted as RW and RO. The names of the mount points are .cell_name and = cell_name (without dot) respectively. My question is: If i need to issue a RW operation, must I accede throught .cell_name? Or = can I accede throught the RO volume cell_name and if i want modify a = file, afs do it for me in the correct volume?=20 Than you very much. Carlos Montero ------=_NextPart_000_0028_01C405AF.E248BD10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
I=B4ve started to use openafs sometime = ago, and I=20 have a question. It=B4s possible you can help me. In my cell I have the = volumes=20 root.afs mounted as RW and RO. The names of the mount points are = .cell_name and=20 cell_name (without dot) respectively. My question is:
If i need to issue a RW = operation, must=20 I accede throught .cell_name? Or can I accede throught the RO = volume=20 cell_name and if i want modify a file, afs do it for me in the correct = volume?=20
Than you very much.
 
    Carlos=20 Montero
------=_NextPart_000_0028_01C405AF.E248BD10-- From fbo2@gmx.net Tue Mar 9 09:02:39 2004 From: fbo2@gmx.net (Frank Burkhardt) Date: Tue, 9 Mar 2004 10:02:39 +0100 Subject: [OpenAFS] How to convert RO- to RW-Volumes In-Reply-To: <404C97AF.8080401@rzg.mpg.de> References: <20040308143729.GA29666@fbo.no-ip.org> <404C97AF.8080401@rzg.mpg.de> Message-ID: <20040309090239.GA14010@fbo.no-ip.org> On Mon, Mar 08, 2004 at 04:56:31PM +0100, Hartmut Reuter wrote: > > I wrote a "vos convert" two years ago for MR-AFS and Thomas M?ller from > tu.chemnitz.de > ported this to OpenAFS and has based his backup concept on this feature. > So ask him where to get it. (It requires also changes to the volserver, > of course, not > just to the vos command). I'll ask him by private mail. Thank you. Regards, Frank From openafs@gnosys.biz Tue Mar 9 17:44:17 2004 From: openafs@gnosys.biz (Kevin) Date: Tue, 9 Mar 2004 12:44:17 -0500 Subject: [OpenAFS] Tickets, tokens, foreign cells, etc. Message-ID: <200403091244.17807.openafs@gnosys.biz> Hi All- This started as a much longer post which I just filed away in my drafts folder because I may be able to distill it down to something more succinct: Questions: 1) As an AFS user defined in the pts database (without admin privileges), should I be able to see foreign cells that are mounted at /afs/foreign_cell when logged in to any client machine that mounts the AFS filesystem at /afs? I can see them when I'm logged in as such as user to the _server_ machine (also configured as a client), but not when logged in as such a user to a client-only machine. Do I have to explicitly make each foreign cell available on each client machine somehow? 2) The login process on the client machine automatically (using pam) obtains both a krbtgt and an afs service ticket (I'm using MIT kerby 5 for auth). Immediately after logging in, the output of the tokens command is: jg@athena:~> /usr/afsws/bin/tokens Tokens held by the Cache Manager: Tokens for afs@folkvang.org [Expires ...] --End of list-- jg@athena:~> (It doesn't list the user's AFS ID) But when I kinit as this same user on the server machine, and then do aklog (not the pam guided login process on the client-only machine), and then do a tokens command, I get: Tokens held by the Cache Manager: User's (AFS ID 1000) tokens for afs@folkvang.org [Expires...] the tokens command is the very same binary file in each case, made available to the client-only machine via the AFS filesystem. Apparently, the kinit/aklog process does something slightly different than the pam assisted one-step login process: it is seeing and pulling in to the Cache Manager the AFS ID whereas the pam assisted login process (which does obtain krbtgt as kinit would, and the afs/folkvang.org@FOLKVANG.ORG service ticket, and apparently also the AFS token afs@folkvang.org) does not bring the AFS ID along. So my question (2) is: is this absence of the AFS ID as seen in the output of the tokens command going to cause me any problems? Both AFS server/client and AFS client-only machines are i386_linux24 machines running the SuSE 9 distro as a base, but with MIT Kerberos 5 built from source and OpenAFS 1.2.11 also built from source. The pam configuration queries an OpenLDAP server for user data first, then the local /etc/passwd files if that fails, then gets kerberos tickets (I think I have the ordering correct here). But I'm worried that something subtle (and problematic) may be associated with the absence of the AFS ID in the output of the tokens command. As this user, I can see files in my local cell's AFS filesystem with ACL of system:authuser rl, so that much is working, but could this be a problem elsewhere? This turned out to be longer than I had hoped, but still much less lengthy than what I filed away. Apologies for the length. TIA for any help. -Kevin From Sergio.Gelato@astro.su.se Tue Mar 9 06:45:11 2004 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Tue, 9 Mar 2004 07:45:11 +0100 Subject: [OpenAFS] qmail and user mail accounts in AFS In-Reply-To: <20040226190942.GE2148@catalepsy> References: <18564.1077561256@www25.gmx.net> <20040224163357.GG29343@kalmia.hozed.org> <20040226190942.GE2148@catalepsy> Message-ID: <20040309064509.GB30705@astro.su.se> * bucy-openafs@gloop.org [2004-02-26 14:09:42 -0500]: > On Tue, Feb 24, 2004 at 10:33:57AM -0600, Troy Benjegerdes wrote: > > > I have a script that starts up courier-imap and courier-mta with tokens > > for a user called 'mail' that has ACL's for all the user's maildirs. > > We contemplated this and its a bad idea if you allow a user to put > arbitrary shellcode in .qmail -- any user's delivery can clobber any > other user's mail since they're all running with the same creds. True, although if you tighten up the ACLs on the maildirs (lidk on tmp/, lik on new/ for the mail user) what you get is "only" denial of service and mailbox poisoning attacks, no clobbering of legitimate email. By "mailbox poisoning" I mean the insertion of a perfect forgery in which not even the first Received: header is authentic. Of course that's already bad enough. > (i.e. there's a user/mail princ/user.mail pts user for each user which > in turn only has rights on the user's maildir) Burns up twice as many uids, but if you can afford that it's the way to go. From forrie@forrie.com Tue Mar 9 17:00:19 2004 From: forrie@forrie.com (Forrest Aldrich) Date: Tue, 09 Mar 2004 12:00:19 -0500 Subject: [OpenAFS] FreeBSD status? Message-ID: <404DF823.6000108@forrie.com> What's the status of OpenAFS with FreeBSD (5.x) at this time? Thanks... From rlink+@pitt.edu Tue Mar 9 19:05:39 2004 From: rlink+@pitt.edu (Ray Link) Date: Tue, 09 Mar 2004 14:05:39 -0500 (EST) Subject: [OpenAFS] Tickets, tokens, foreign cells, etc. In-Reply-To: <200403091244.17807.openafs@gnosys.biz> References: <200403091244.17807.openafs@gnosys.biz> Message-ID: On Tue, 9 Mar 2004, Kevin wrote: > Questions: > 1) As an AFS user defined in the pts database (without > admin privileges), should I be able to see foreign > cells that are mounted at /afs/foreign_cell when > logged in to any client machine that mounts the AFS > filesystem at /afs? I can see them when I'm logged in > as such as user to the _server_ machine (also > configured as a client), but not when logged in as > such a user to a client-only machine. Do I have to > explicitly make each foreign cell available on each > client machine somehow? It sounds like you don't have explicit mountpoints for the foreign cells in your root.afs volume, and are using -dynroot on the server/clients but not on the client-only hosts. ==== Ray Link === University of Pittsburgh CSSD === rlink@pitt.edu ==== ==== PGP/GPG Key: http://www.pitt.edu/~rlink/gpgkey.asc.txt ==== Sugar makes the world go 'round. Caffeine makes it spin faster. From jhutz@cmu.edu Tue Mar 9 19:09:11 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Tue, 09 Mar 2004 14:09:11 -0500 Subject: [OpenAFS] Tickets, tokens, foreign cells, etc. In-Reply-To: <200403091244.17807.openafs@gnosys.biz> References: <200403091244.17807.openafs@gnosys.biz> Message-ID: <1749472704.1078859351@minbar.fac.cs.cmu.edu> On Tuesday, March 09, 2004 12:44:17 -0500 Kevin wrote: > 1) As an AFS user defined in the pts database (without > admin privileges), should I be able to see foreign > cells that are mounted at /afs/foreign_cell when > logged in to any client machine that mounts the AFS > filesystem at /afs? I can see them when I'm logged in > as such as user to the _server_ machine (also > configured as a client), but not when logged in as > such a user to a client-only machine. Do I have to > explicitly make each foreign cell available on each > client machine somehow? In order for a cell to be accessible on any given client (including one which is also an AFS server), it normally must appear in the CellServDB on that machine. In most cases, this file is /etc/openafs/CellServDB or /usr/vice/etc/CellServDB, depending on whether your OpenAFS was built with GNU-style paths or Transarc-style paths. The CellServDB file is processed by afsd on startup, so adding things to it after AFS is already running won't have much effect. However, you can use the 'fs newcell' command to inform the running cache manager about a new cell, or changes to the set of database servers for an existing cell. If you start afsd with the --afsdb switch, then cells which publish AFSDB records in DNS need not appear in the CellServDB file; the cache manager will use the AFSDB records to find database servers for such cells. > So my question (2) is: is this absence of the AFS ID as > seen in the output of the tokens command going to > cause me any problems? Nope. This is entirely dependent on whether whatever tool you used to set tokens bothered to store an ID. Some tools look up your ID in the pts database, some just use your unix UID, and some don't bother to set an ID at all. AFS itself doesn't use this feature; it was there entirely for the benefit of a small number of tools that thought they wanted to know what your AFS ID was. The only known tools that use this "feature" are certain components of the Andrew Message System. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From rees@umich.edu Tue Mar 9 19:16:15 2004 From: rees@umich.edu (Jim Rees) Date: Tue, 09 Mar 2004 14:16:15 -0500 Subject: [OpenAFS] FreeBSD status? In-Reply-To: Forrest Aldrich, Tue, 09 Mar 2004 12:00:19 EST Message-ID: <20040309191615.4994D2098E@citi.umich.edu> What's the status of OpenAFS with FreeBSD (5.x) at this time? I've got a guy testing the server right now. There is a patch that makes the client work. I will be committing this patch some time this week, after I make sure it doesn't break 4.x or OpenBSD. The client is very new and untested and crashes a lot but there should be rapid progress after I do the commit. From openafs@gnosys.biz Tue Mar 9 19:39:14 2004 From: openafs@gnosys.biz (Kevin) Date: Tue, 9 Mar 2004 14:39:14 -0500 Subject: [OpenAFS] Tickets, tokens, foreign cells, etc. In-Reply-To: <1749472704.1078859351@minbar.fac.cs.cmu.edu> References: <200403091244.17807.openafs@gnosys.biz> <1749472704.1078859351@minbar.fac.cs.cmu.edu> Message-ID: <200403091439.14097.openafs@gnosys.biz> Thank you both. That answered both my questions. -Kevin From gug.ml@laposte.net Wed Mar 10 09:31:32 2004 From: gug.ml@laposte.net (gug.ml) Date: Wed, 10 Mar 2004 10:31:32 +0100 Subject: [OpenAFS] OpenAFS and LDAP Message-ID: Hello, First sorry for my poor english :( So, i have got an OpenLd= ap server that authenticate user through TLS. I'm not using a kerberos s= erver. I'd like taht openAFS contact the ldap server in order to have=0D = the login/pass and authorize (or not) the client to mount (/home/ or oth= er). Can openAFS do it ? (without kerberos) and if you ve got a web s= ite ;) thanks in advance benoit. sorry for my poor english=0A=0AAc= c=E9dez au courrier =E9lectronique de La Poste : www.laposte.net ; =0A361= 5 LAPOSTENET (0,34=80/mn) ; t=E9l : 08 92 68 13 50 (0,34=80/mn)=0A=0A From cpenney@ford.com Wed Mar 10 13:50:30 2004 From: cpenney@ford.com (Penney Jr., Christopher (C.)) Date: Wed, 10 Mar 2004 08:50:30 -0500 Subject: [OpenAFS] File Size Limitations Message-ID: <752E6D5014672D458A593B5E7A3CD5F504E93D0E@na1fcm51.dearborn.ford.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C406A6.A6C4CC46 Content-Type: text/plain How exactly does the file size limitation show up in OpenAFS (ie. 2GB per file maximum)? I've been told that the maximum file size depends on a couple of factors and I'm trying to figure out what they are. Right now I have a test environment with a couple of Solaris 9 boxes (one the file server and one a client) and I'm seeing a 2GB per file size limitation. Chris ------_=_NextPart_001_01C406A6.A6C4CC46 Content-Type: text/html Message
How exactly does the file size limitation show up in OpenAFS (ie. 2GB per file maximum)?  I've been told that the maximum file size depends on a couple of factors and I'm trying to figure out what they are.  Right now I have a test environment with a couple of Solaris 9 boxes (one the file server and one a client) and I'm seeing a 2GB per file size limitation.
 
   Chris
 
------_=_NextPart_001_01C406A6.A6C4CC46-- From jnurmi-openafs-info@qwe.cc Wed Mar 10 13:59:31 2004 From: jnurmi-openafs-info@qwe.cc (J. D. Nurmi) Date: Wed, 10 Mar 2004 08:59:31 -0500 Subject: [OpenAFS] OpenAFS and LDAP In-Reply-To: References: Message-ID: <1078927171.2482.3.camel@qwe.cc> Unfortunately, OpenAFS requires either the ingrown kerberos, or another kerberos server... What you _can_ do is set up openLDAP to authenticate through SASL, which in turn can authenticate through Kerberos. This is what we do at my office, and it tends to work well. (If you need more info, google for SASL, Kerberos and OpenLDAP) James On Wed, 2004-03-10 at 04:31, gug.ml wrote: > Hello, > > First sorry for my poor english :( > > So, i have got an OpenLdap server that authenticate user > through TLS. I'm not using a kerberos server. > I'd like taht openAFS contact the ldap server in order to have > the login/pass and authorize (or not) the client to mount > (/home/ or other). > > Can openAFS do it ? (without kerberos) > and if you ve got a web site ;) > > thanks in advance > benoit. > > sorry for my poor english > > Accédez au courrier électronique de La Poste : www.laposte.net ; > 3615 LAPOSTENET (0,34¤/mn) ; tél : 08 92 68 13 50 (0,34¤/mn) > > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From reuter@rzg.mpg.de Wed Mar 10 14:16:07 2004 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Wed, 10 Mar 2004 15:16:07 +0100 Subject: [OpenAFS] File Size Limitations In-Reply-To: <752E6D5014672D458A593B5E7A3CD5F504E93D0E@na1fcm51.dearborn.ford.com> References: <752E6D5014672D458A593B5E7A3CD5F504E93D0E@na1fcm51.dearborn.ford.com> Message-ID: <404F2327.4000005@rzg.mpg.de> With the stable releases (which are not compiled with large file support) the maximum filesize is (2GB - chunksize). With instable 1.3.52 you have large file support on the client and (as far as I know) on the server side. However, on the client side it's available only for AIX (4.2 - 5.2), Linux 2.4 and (Solaris >=8 with 64bit kernel), unless someone else has done the work. Hartmut Penney Jr., Christopher (C.) wrote: > How exactly does the file size limitation show up in OpenAFS (ie. 2GB > per file maximum)? I've been told that the maximum file size depends on > a couple of factors and I'm trying to figure out what they are. Right > now I have a test environment with a couple of Solaris 9 boxes (one the > file server and one a client) and I'm seeing a 2GB per file size limitation. > > Chris > -- ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 RZG (Rechenzentrum Garching) fax +49-89-3299-1301 Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From deengert@anl.gov Wed Mar 10 14:56:59 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Mar 2004 08:56:59 -0600 Subject: [OpenAFS] OpenAFS and LDAP References: Message-ID: <404F2CBB.C0EE26C@anl.gov> "gug.ml" wrote: > > Hello, > > First sorry for my poor english :( > > So, i have got an OpenLdap server that authenticate user > through TLS. I'm not using a kerberos server. > I'd like taht openAFS contact the ldap server in order to have > > the login/pass and authorize (or not) the client to mount > (/home/ or other). > > Can openAFS do it ? (without kerberos) > and if you ve got a web site ;) Yes it can be done without Kerberos and use X509 certificates and TLS. GSI implements a GSSAPI mechanism that uses X509 certificates and TLS to authenticate. The gssklog program on the client uses the gssapi to authenticate to the gssklogd running on the AFS database servers. The gssklogd returns an AFS token to the client. gssklog can be used with any GSSAPI SO if you have so other implementation it should work. It also works with Kerberos GSSAPI implementations such as MIT, Heimdal, SEAM and Microsoft SSPI. And it runs on Windows. So with AFS you don't need a kaserver, but still need the PTS or some replacement for it. The AFS token is still Kerberos, but the user never sees this, only the gssklog program which passes it off to the kernel. In effect the gssklogd is issuing AFS tokens which are in effect Kerberos tickets used internally by AFS only. See:ftp://achilles.ctd.anl.gov/pub/DEE/README.GSSKLOG ftp://achilles.ctd.anl.gov/pub/DEE/gssklog-0.10.tar http://www.globus.org/security/ > > thanks in advance > benoit. > > sorry for my poor english > > Accédez au courrier électronique de La Poste : www.laposte.net ; > 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn) > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Bdcneal@budget.state.ny.us Wed Mar 10 15:17:12 2004 From: Bdcneal@budget.state.ny.us (Mark Neal) Date: Wed, 10 Mar 2004 10:17:12 -0500 Subject: [OpenAFS] setup Message-ID: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_C3E2C195.DEBFDBCD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable i'm trying to set up my initial afs server. when i get to the "vos = create", i get a message that the partition doesn't exist on my server = (but it does). =20 ---------------------------------------------------------------------------= ------------------------ command=3D=3D> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth error msg=3D=3D> vos : partition /vicepmn does not exist on the server =20 /etc/fstab=3D=3D> LABEL=3D/vicepmn /vicepmn ext2 = defaults,noatime 0 2 /etc/mtab=3D=3D> /dev/sdb1 /vicepmn ext2 rw,noatime 0 0 =20 df -hTl=3D=3D=3D=3D> /dev/sdb1 ext2 9.7G 16K 9.2G 1% /vicepmn ---------------------------------------------------------------------------= ------------------------ =20 what am i missing? =20 =20 =20 Mark Neal System Administrator - Web Services NYS Division of Budget (518) 402-4181 =20 =20 --=_C3E2C195.DEBFDBCD Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Description: HTML
i'm trying to set up my initial afs server. when i get = to the=20 "vos create", i get a message that the partition doesn't exist on my = server (but=20 it does).
 
------------------------------------------------------------------= ---------------------------------
command=3D=3D> ./vos create aaa.bbb /vicepmn = root.afs -cell ccc=20 -noauth
error msg=3D=3D> vos : partition /vicepmn does not exist on = the=20 server
 
/etc/fstab=3D=3D>=20 LABEL=3D/vicepmn         =20 /vicepmn           &= nbsp;   =20 ext2    defaults,noatime 0 2
/etc/mtab=3D=3D> /dev/sdb1 /vicepmn ext2 rw,noatime = 0=20 0
 
df -hTl=3D=3D=3D=3D> /dev/sdb1   &nbs= p;=20 ext2    9.7G   16K  9.2G   1%=20 /vicepmn
------------------------------------------------------------------= ---------------------------------
 
what am i missing?
 
 
 
Mark Neal
System Administrator - Web Services
NYS Division = of=20 Budget
(518) 402-4181
 
 
--=_C3E2C195.DEBFDBCD-- From jnurmi-openafs-info@qwe.cc Wed Mar 10 15:35:22 2004 From: jnurmi-openafs-info@qwe.cc (J. D. Nurmi) Date: Wed, 10 Mar 2004 10:35:22 -0500 Subject: [OpenAFS] OpenAFS and LDAP In-Reply-To: <404F2CBB.C0EE26C@anl.gov> References: <404F2CBB.C0EE26C@anl.gov> Message-ID: <1078932922.2482.5.camel@qwe.cc> I stand corrected *sheepish grin* On Wed, 2004-03-10 at 09:56, Douglas E. Engert wrote: > "gug.ml" wrote: > > > > Hello, > > > > First sorry for my poor english :( > > > > So, i have got an OpenLdap server that authenticate user > > through TLS. I'm not using a kerberos server. > > I'd like taht openAFS contact the ldap server in order to have > > > > the login/pass and authorize (or not) the client to mount > > (/home/ or other). > > > > Can openAFS do it ? (without kerberos) > > and if you ve got a web site ;) > > Yes it can be done without Kerberos and use X509 certificates > and TLS. GSI implements a GSSAPI mechanism that uses X509 > certificates and TLS to authenticate. The gssklog program on the > client uses the gssapi to authenticate to the gssklogd running on > the AFS database servers. The gssklogd returns an AFS token to the client. > > gssklog can be used with any GSSAPI SO if you have so other > implementation it should work. It also works with Kerberos GSSAPI > implementations such as MIT, Heimdal, SEAM and Microsoft SSPI. > And it runs on Windows. > > So with AFS you don't need a kaserver, but still need the PTS > or some replacement for it. The AFS token is still Kerberos, but the > user never sees this, only the gssklog program which passes it off > to the kernel. > > In effect the gssklogd is issuing AFS tokens which are in effect Kerberos > tickets used internally by AFS only. > > > > > See:ftp://achilles.ctd.anl.gov/pub/DEE/README.GSSKLOG > ftp://achilles.ctd.anl.gov/pub/DEE/gssklog-0.10.tar > http://www.globus.org/security/ > > > > > > > thanks in advance > > benoit. > > > > sorry for my poor english > > > > Accédez au courrier électronique de La Poste : www.laposte.net ; > > 3615 LAPOSTENET (0,34¤/mn) ; tél : 08 92 68 13 50 (0,34¤/mn) > > > > _______________________________________________ > > OpenAFS-info mailing list > > OpenAFS-info@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-info From hendrik.hoeth@cern.ch Wed Mar 10 15:38:02 2004 From: hendrik.hoeth@cern.ch (Hendrik Hoeth) Date: Wed, 10 Mar 2004 16:38:02 +0100 Subject: [OpenAFS] setup In-Reply-To: References: Message-ID: <20040310153802.GD30885@mail.physik.uni-wuppertal.de> Thus spake Mark Neal (Bdcneal@budget.state.ny.us): > command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth ^^^^^^^^ try mn here -- for (Int_t j = 0; j < 100; j++){ // ROOT Users Guide 3.10, p. 243 if (j < 100){ smallHisto->Fill(fTracks_fPx[j]); } } From bartonjs@cs.rose-hulman.edu Wed Mar 10 15:47:12 2004 From: bartonjs@cs.rose-hulman.edu (Jeremy S Barton) Date: Wed, 10 Mar 2004 10:47:12 -0500 (EST) Subject: [OpenAFS] setup In-Reply-To: Message-ID: On Wed, 10 Mar 2004, Mark Neal wrote: > i'm trying to set up my initial afs server. when i get to the "vos > create", i get a message that the partition doesn't exist on my server > (but it does). > command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth > what am i missing? It's not what you're missing, it's what you added, actually. remove the / from /vicepmn and it should work: vos create aaa.bbb vicepmn root.afs -Jeremy From deengert@anl.gov Wed Mar 10 16:09:13 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Mar 2004 10:09:13 -0600 Subject: [OpenAFS] OpenAFS and LDAP References: <404F2CBB.C0EE26C@anl.gov> <1078932922.2482.5.camel@qwe.cc> Message-ID: <404F3DA9.65CE2FC9@anl.gov> "J. D. Nurmi" wrote: > > I stand corrected *sheepish grin* I did not mean to correct you, but to indicate that there are other options. The gssklog with GSI is not ldap, but does show that there are other ways to get a token without a Kerberos realm. > > On Wed, 2004-03-10 at 09:56, Douglas E. Engert wrote: > > "gug.ml" wrote: > > > > > > Hello, > > > > > > First sorry for my poor english :( > > > > > > So, i have got an OpenLdap server that authenticate user > > > through TLS. I'm not using a kerberos server. > > > I'd like taht openAFS contact the ldap server in order to have > > > > > > the login/pass and authorize (or not) the client to mount > > > (/home/ or other). > > > > > > Can openAFS do it ? (without kerberos) > > > and if you ve got a web site ;) > > > > Yes it can be done without Kerberos and use X509 certificates > > and TLS. GSI implements a GSSAPI mechanism that uses X509 > > certificates and TLS to authenticate. The gssklog program on the > > client uses the gssapi to authenticate to the gssklogd running on > > the AFS database servers. The gssklogd returns an AFS token to the client. > > > > gssklog can be used with any GSSAPI SO if you have so other > > implementation it should work. It also works with Kerberos GSSAPI > > implementations such as MIT, Heimdal, SEAM and Microsoft SSPI. > > And it runs on Windows. > > > > So with AFS you don't need a kaserver, but still need the PTS > > or some replacement for it. The AFS token is still Kerberos, but the > > user never sees this, only the gssklog program which passes it off > > to the kernel. > > > > In effect the gssklogd is issuing AFS tokens which are in effect Kerberos > > tickets used internally by AFS only. > > > > > > > > > > See:ftp://achilles.ctd.anl.gov/pub/DEE/README.GSSKLOG > > ftp://achilles.ctd.anl.gov/pub/DEE/gssklog-0.10.tar > > http://www.globus.org/security/ > > > > > > > > > > > > thanks in advance > > > benoit. > > > > > > sorry for my poor english > > > > > > Accédez au courrier électronique de La Poste : www.laposte.net ; > > > 3615 LAPOSTENET (0,34¤/mn) ; tél : 08 92 68 13 50 (0,34¤/mn) > > > > > > _______________________________________________ > > > 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 -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From wjustice@ford.com Wed Mar 10 18:19:33 2004 From: wjustice@ford.com (Justice, William (WJJ.)) Date: Wed, 10 Mar 2004 13:19:33 -0500 Subject: [OpenAFS] setup Message-ID: <404F5C35.9010106@ford.com> This is a cryptographically signed message in MIME format. --------------ms000101010006010504060201 Content-Type: multipart/alternative; boundary="------------050408070507000508050401" This is a multi-part message in MIME format. --------------050408070507000508050401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I'm having the same issue, and I don't follow the hint below, tried both with and with out the "/" in /vicepxx /*command==> ./vos create myhost.com vicepxx root.afs -cell mycell.com vos : partition vicepxx does not exist on the server *//*command==> df -h /vicepxx Filesystem Size Used Avail Use% Mounted on /dev/AFS/AFS 50G 33M 47G 1% /vicepxx */ Thanks, Bill "The box said I needed to install Windows 98 or better... so I installed Linux" Message: 2 Date: Wed, 10 Mar 2004 16:38:02 +0100 From: Hendrik Hoeth To: openafs-info@openafs.org Subject: Re: [OpenAFS] setup Thus spake Mark Neal (Bdcneal@budget.state.ny.us): > command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth ^^^^^^^^ try mn here -- for (Int_t j = 0; j < 100; j++){ // ROOT Users Guide 3.10, p. 243 if (j < 100){ smallHisto->Fill(fTracks_fPx[j]); } } --__--__-- From: Jeremy S Barton To: Mark Neal Cc: Subject: Re: [OpenAFS] setup On Wed, 10 Mar 2004, Mark Neal wrote: > i'm trying to set up my initial afs server. when i get to the "vos > create", i get a message that the partition doesn't exist on my server > (but it does). > command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth > what am i missing? It's not what you're missing, it's what you added, actually. remove the / from /vicepmn and it should work: vos create aaa.bbb vicepmn root.afs -Jeremy --__--__-- --------------050408070507000508050401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

I'm having the same issue, and I don't follow the hint below,  tried both with and with out the "/" in /vicepxx

command==> ./vos create myhost.com vicepxx root.afs -cell mycell.com
vos : partition vicepxx does not exist on the server
command==> df -h /vicepxx
Filesystem            Size  Used Avail Use% Mounted on
/dev/AFS/AFS           50G   33M   47G   1% /vicepxx

Thanks,
Bill

"The box said I needed to install Windows 98 or better… so I installed Linux"

Message: 2
Date: Wed, 10 Mar 2004 16:38:02 +0100
From: Hendrik Hoeth <hendrik.hoeth@cern.ch>
To: openafs-info@openafs.org
Subject: Re: [OpenAFS] setup

Thus spake Mark Neal (Bdcneal@budget.state.ny.us):

> command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth
                                  ^^^^^^^^
                                try mn here

--
for (Int_t j = 0; j < 100; j++){        // ROOT Users Guide 3.10, p. 243
  if (j < 100){
    smallHisto->Fill(fTracks_fPx[j]);
  }
}

--__--__--

From: Jeremy S Barton <bartonjs@cs.rose-hulman.edu>
To: Mark Neal <Bdcneal@budget.state.ny.us>
Cc: <openafs-info@openafs.org>
Subject: Re: [OpenAFS] setup

On Wed, 10 Mar 2004, Mark Neal wrote:

> i'm trying to set up my initial afs server. when i get to the "vos
> create", i get a message that the partition doesn't exist on my server
> (but it does).

> command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth
> what am i missing?

It's not what you're missing, it's what you added, actually.  remove the /
from /vicepmn and it should work:
vos create aaa.bbb vicepmn root.afs

-Jeremy


--__--__--






--------------050408070507000508050401--

--------------ms000101010006010504060201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINTTCC
A8kwggMyoAMCAQICEAkp4zT/pNCLWoEO6S63nKwwDQYJKoZIhvcNAQEEBQAwgcExCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJs
aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykg
MTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTk5MDExOTAwMDAwMFoXDTA5MDExODIzNTk1
OVowgdsxDTALBgNVBAoTBEZvcmQxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS
ZWYuLExJQUIuTFREKGMpOTgxMjAwBgNVBAsTKUNsYXNzIDIgQ0EgLSBPblNpdGUgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyMS0wKwYDVQQDEyRGb3JkIE1vdG9yIENvbXBhbnkgLSBWZXJpU2ln
biBPblNpdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMiDa8aw48w8mgJ3AGqaVdYy
/F/ki3JrZrRjFYpn36hlxA+WrEBM9nZnLIfQ+HHj4KYkeellf9KpDGdOeiJb4Na+ybriLeaE
p7BXIu91xvftq1/mIbA4Fz0jZNq+JHQwS0czSpjAw1mxfwHF9VweoPokHkwUdS1WJEQLDIVq
+YQTAgMBAAGjgaUwgaIwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEt
MTA0MBEGCWCGSAGG+EIBAQQEAwIBBjBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBwEBMCowKAYI
KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9SUEEwDwYDVR0TBAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEABpnmsPQt2gDfVegXjI6ytXBxIW/X
1wRdpWYzv/ZliJv3EYBkg3ymJpeYWhqWlKNw4ApyztW8q0w7WQQAm8eIV5qVZIDlsEUTidH2
yrM3QSR61wiSq+9RYqHagdaFGZ+35PstR9yEcgOeoC6iTZwJHYwNRZlhjGePTIaNeIjdnLMw
ggS8MIIEJaADAgECAhAhAJSFP4l7p65vZtwjlB6uMA0GCSqGSIb3DQEBBAUAMIHbMQ0wCwYD
VQQKEwRGb3JkMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13
d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU
RChjKTk4MTIwMAYDVQQLEylDbGFzcyAyIENBIC0gT25TaXRlIEluZGl2aWR1YWwgU3Vic2Ny
aWJlcjEtMCsGA1UEAxMkRm9yZCBNb3RvciBDb21wYW55IC0gVmVyaVNpZ24gT25TaXRlMB4X
DTAzMDcyOTAwMDAwMFoXDTA0MDcyODIzNTk1OVowaDENMAsGA1UEChMEZm9yZDEQMA4GA1UE
CxMHZm9yZG5hMTETMBEGA1UEAxMKUmVjaXBpZW50czEwMC4GA1UEAxMnV0pVU1RJQ0UgKHdq
dXN0aWNlLCBGb3JkIE1vdG9yIENvbXBhbnkpMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDrud0JL0bg35jIDPw+vaymW0Wm+SbpaWhV+igDcFNJUCS319e9QX8lvim/c0gkrUeul6/w
kDlGAtXiirG8TovNnQpjiFbt9lAV1JDBH9XymEMYrB80tu4M9mXPKB5nq2oJBmCokOgpbLYh
XVKPnNZ3jaNT2LJI8/8zZySu5B/ZjQIDAQABo4IB8TCCAe0wCQYDVR0TBAIwADAcBgNVHREE
FTATgRF3anVzdGljZUBmb3JkLmNvbTCCASQGA1UdIASCARswggEXMIIBEwYLYIZIAYb4RQEH
AQYwggECMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMIHS
BggrBgEFBQcCAjCBxRqBwk5PVElDRTogUHJpdmF0ZSBrZXkgbWF5IGJlIHJlY292ZXJlZCBi
eSBWZXJpU2lnbidzIGN1c3RvbWVyIHdobyBtYXkgYmUgYWJsZSB0byBkZWNyeXB0IG1lc3Nh
Z2VzIHlvdSBzZW5kIHRvIGNlcnRpZmljYXRlIGhvbGRlci4gIFVzZSBpcyBzdWJqZWN0IHRv
IHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkuMBEGCWCG
SAGG+EIBAQQEAwIHgDBbBgNVHR8EVDBSMFCgTqBMhkpodHRwOi8vb25zaXRlY3JsLnZlcmlz
aWduLmNvbS9Gb3JkTW90b3JDb21wYW55RXhjaGFuZ2VPblNpdGUvTGF0ZXN0Q1JMLmNybDAL
BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEB
BAUAA4GBAHVDFetUWXCfAKd9TRLRwfgn87HQtY89BuuxGh1xs5sPqTYiqI8vqdbW9nxwhhjn
DY/JYcSh4URBmVoOElna0cXI536fNRgBULyzKpf9xmz04Awi8mLIOW3q0JuDf2ItheDgW9xs
AgE4T6ApNRhfJC7rkyWAjV7a2J3T2/LloUKoMIIEvDCCBCWgAwIBAgIQIQCUhT+Je6eub2bc
I5QerjANBgkqhkiG9w0BAQQFADCB2zENMAsGA1UEChMERm9yZDEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEyMDAGA1UECxMpQ2xhc3MgMiBD
QSAtIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIxLTArBgNVBAMTJEZvcmQgTW90b3Ig
Q29tcGFueSAtIFZlcmlTaWduIE9uU2l0ZTAeFw0wMzA3MjkwMDAwMDBaFw0wNDA3MjgyMzU5
NTlaMGgxDTALBgNVBAoTBGZvcmQxEDAOBgNVBAsTB2ZvcmRuYTExEzARBgNVBAMTClJlY2lw
aWVudHMxMDAuBgNVBAMTJ1dKVVNUSUNFICh3anVzdGljZSwgRm9yZCBNb3RvciBDb21wYW55
KTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA67ndCS9G4N+YyAz8Pr2spltFpvkm6Wlo
VfooA3BTSVAkt9fXvUF/Jb4pv3NIJK1Hrpev8JA5RgLV4oqxvE6LzZ0KY4hW7fZQFdSQwR/V
8phDGKwfNLbuDPZlzygeZ6tqCQZgqJDoKWy2IV1Sj5zWd42jU9iySPP/M2ckruQf2Y0CAwEA
AaOCAfEwggHtMAkGA1UdEwQCMAAwHAYDVR0RBBUwE4ERd2p1c3RpY2VAZm9yZC5jb20wggEk
BgNVHSAEggEbMIIBFzCCARMGC2CGSAGG+EUBBwEGMIIBAjArBggrBgEFBQcCARYfaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjCB0gYIKwYBBQUHAgIwgcUagcJOT1RJQ0U6IFBy
aXZhdGUga2V5IG1heSBiZSByZWNvdmVyZWQgYnkgVmVyaVNpZ24ncyBjdXN0b21lciB3aG8g
bWF5IGJlIGFibGUgdG8gZGVjcnlwdCBtZXNzYWdlcyB5b3Ugc2VuZCB0byBjZXJ0aWZpY2F0
ZSBob2xkZXIuICBVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5LjARBglghkgBhvhCAQEEBAMCB4AwWwYDVR0fBFQwUjBQ
oE6gTIZKaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vRm9yZE1vdG9yQ29tcGFueUV4
Y2hhbmdlT25TaXRlL0xhdGVzdENSTC5jcmwwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQB1QxXrVFlwnwCnfU0S0cH4J/Ox
0LWPPQbrsRodcbObD6k2IqiPL6nW1vZ8cIYY5w2PyWHEoeFEQZlaDhJZ2tHFyOd+nzUYAVC8
syqX/cZs9OAMIvJiyDlt6tCbg39iLYXg4FvcbAIBOE+gKTUYXyQu65MlgI1e2tid09vy5aFC
qDGCBFgwggRUAgEBMIHwMIHbMQ0wCwYDVQQKEwRGb3JkMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB
IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MTIwMAYDVQQLEylDbGFzcyAyIENBIC0g
T25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlcjEtMCsGA1UEAxMkRm9yZCBNb3RvciBDb21w
YW55IC0gVmVyaVNpZ24gT25TaXRlAhAhAJSFP4l7p65vZtwjlB6uMAkGBSsOAwIaBQCgggK9
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxMDE4MTkz
M1owIwYJKoZIhvcNAQkEMRYEFKGGV1Te7I5w61/tJ7ZZR5MIp3C6MFIGCSqGSIb3DQEJDzFF
MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgEoMIIBAQYJKwYBBAGCNxAEMYHzMIHwMIHbMQ0wCwYDVQQKEwRGb3Jk
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp
Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MTIw
MAYDVQQLEylDbGFzcyAyIENBIC0gT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlcjEtMCsG
A1UEAxMkRm9yZCBNb3RvciBDb21wYW55IC0gVmVyaVNpZ24gT25TaXRlAhAhAJSFP4l7p65v
ZtwjlB6uMIIBAwYLKoZIhvcNAQkQAgsxgfOggfAwgdsxDTALBgNVBAoTBEZvcmQxHzAdBgNV
BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20v
cmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxMjAwBgNVBAsT
KUNsYXNzIDIgQ0EgLSBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyMS0wKwYDVQQDEyRG
b3JkIE1vdG9yIENvbXBhbnkgLSBWZXJpU2lnbiBPblNpdGUCECEAlIU/iXunrm9m3COUHq4w
DQYJKoZIhvcNAQEBBQAEgYB3MDanrEoOdiPWFJiKl2sKP1ls+zfTnOBNqsIPlfN7jacCayVW
uYUZBN2UjVAzpduinsweGMh1PP+lQwzxvE+TUXaAay7oLoxJfjZupW54Q12jq7LYFc8aEOuH
BNiqyEW/4uWy6nCuV9YsmmAsWwGB5j6isgbfGA4jAaXkLWTdqwAAAAAAAA==
--------------ms000101010006010504060201--


From lwc@vapid.ath.cx  Wed Mar 10 18:26:36 2004
From: lwc@vapid.ath.cx (Larry W. Cashdollar)
Date: Wed, 10 Mar 2004 13:26:36 -0500 (EST)
Subject: [OpenAFS] setup
In-Reply-To: <404F5C35.9010106@ford.com>
Message-ID: <20040310132601.O19635-100000@vapid.ath.cx>


You might have started the fileserver before you mounted /vicepxx.  I
would stop the fileserver, start it again and give it another try.

-- Larry


On Wed, 10 Mar 2004, Justice, William (WJJ.) wrote:

> I'm having the same issue, and I don't follow the hint below,  tried
> both with and with out the "/" in /vicepxx
>
>     /*command==> ./vos create myhost.com vicepxx root.afs -cell mycell.com
>     vos : partition vicepxx does not exist on the server
>     *//*command==> df -h /vicepxx
>     Filesystem            Size  Used Avail Use% Mounted on
>     /dev/AFS/AFS           50G   33M   47G   1% /vicepxx
>     */
>
> Thanks,
> Bill
>
> "The box said I needed to install Windows 98 or better... so I installed Linux"
>
>     Message: 2
>     Date: Wed, 10 Mar 2004 16:38:02 +0100
>     From: Hendrik Hoeth 
>     To: openafs-info@openafs.org
>     Subject: Re: [OpenAFS] setup
>
>     Thus spake Mark Neal (Bdcneal@budget.state.ny.us):
>
>      > command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth
>                                       ^^^^^^^^
>                                     try mn here
>
>     --
>     for (Int_t j = 0; j < 100; j++){        // ROOT Users Guide 3.10, p.
>     243
>       if (j < 100){
>         smallHisto->Fill(fTracks_fPx[j]);
>       }
>     }
>
>     --__--__--
>
>     From: Jeremy S Barton 
>     To: Mark Neal 
>     Cc: 
>     Subject: Re: [OpenAFS] setup
>
>     On Wed, 10 Mar 2004, Mark Neal wrote:
>
>      > i'm trying to set up my initial afs server. when i get to the "vos
>      > create", i get a message that the partition doesn't exist on my
>     server
>      > (but it does).
>
>      > command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth
>      > what am i missing?
>
>     It's not what you're missing, it's what you added, actually.  remove
>     the /
>     from /vicepmn and it should work:
>     vos create aaa.bbb vicepmn root.afs
>
>     -Jeremy
>
>
>     --__--__--
>
>
>


From dhk@ccre.com  Wed Mar 10 18:24:54 2004
From: dhk@ccre.com (Kim (Dexter) Kimball)
Date: Wed, 10 Mar 2004 11:24:54 -0700
Subject: [OpenAFS] FreeBSD status?
In-Reply-To: <20040309191615.4994D2098E@citi.umich.edu>
Message-ID: 

Jim, could you respond to this inquiry I got from one of our FreeBSD fans?

Thanks.

Kim


On 3/9/2004 7:48:39 PM, Dave (dave@jetcafe.org) wrote:
> Thanks for that info. Is he planning to commit to both 4.X (stable)
> and 5.X (current) branches? If he is,
> I'll pick up his patches and



-----Original Message-----
From: openafs-info-admin@openafs.org
[mailto:openafs-info-admin@openafs.org]On Behalf Of Jim Rees
Sent: Tuesday, March 09, 2004 12:16 PM
To: openafs-info@openafs.org
Subject: Re: [OpenAFS] FreeBSD status?


  What's the status of OpenAFS with FreeBSD (5.x) at this time?

I've got a guy testing the server right now.  There is a patch that makes
the client work.  I will be committing this patch some time this week, after
I make sure it doesn't break 4.x or OpenBSD.  The client is very new and
untested and crashes a lot but there should be rapid progress after I do the
commit.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


From wjustice@ford.com  Wed Mar 10 19:02:38 2004
From: wjustice@ford.com (Justice, William (WJJ.))
Date: Wed, 10 Mar 2004 14:02:38 -0500
Subject: [OpenAFS] setup
Message-ID: <404F664E.8010605@ford.com>

This is a cryptographically signed message in MIME format.

--------------ms020706070101030702050900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Not sure, so I stopped everything, unmounted, mounted again, made sure 
it was mounted, and tried again with the same result...



Larry W. Cashdollar wrote:

>
>
> You might have started the fileserver before you mounted /vicepxx.  I
> would stop the fileserver, start it again and give it another try.
>
> -- Larry
>
>
> On Wed, 10 Mar 2004, Justice, William (WJJ.) wrote:
>
> > I'm having the same issue, and I don't follow the hint below,  tried
> > both with and with out the "/" in /vicepxx
> >
> >     /*command==> ./vos create myhost.com vicepxx root.afs -cell 
> mycell.com
> >     vos : partition vicepxx does not exist on the server
> >     *//*command==> df -h /vicepxx
> >     Filesystem            Size  Used Avail Use% Mounted on
> >     /dev/AFS/AFS           50G   33M   47G   1% /vicepxx
> >     */
> >
> > Thanks,
> > Bill
> >
> > "The box said I needed to install Windows 98 or better... so I 
> installed Linux"
> >
> >     Message: 2
> >     Date: Wed, 10 Mar 2004 16:38:02 +0100
> >     From: Hendrik Hoeth 
> >     To: openafs-info@openafs.org
> >     Subject: Re: [OpenAFS] setup
> >
> >     Thus spake Mark Neal (Bdcneal@budget.state.ny.us):
> >
> >      > command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc 
> -noauth
> >                                       ^^^^^^^^
> >                                     try mn here
> >
> >     --
> >     for (Int_t j = 0; j < 100; j++){        // ROOT Users Guide 
> 3.10, p.
> >     243
> >       if (j < 100){
> >         smallHisto->Fill(fTracks_fPx[j]);
> >       }
> >     }
> >
> >     --__--__--
> >
> >     From: Jeremy S Barton 
> >     To: Mark Neal 
> >     Cc: 
> >     Subject: Re: [OpenAFS] setup
> >
> >     On Wed, 10 Mar 2004, Mark Neal wrote:
> >
> >      > i'm trying to set up my initial afs server. when i get to the 
> "vos
> >      > create", i get a message that the partition doesn't exist on my
> >     server
> >      > (but it does).
> >
> >      > command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc 
> -noauth
> >      > what am i missing?
> >
> >     It's not what you're missing, it's what you added, actually.  
> remove
> >     the /
> >     from /vicepmn and it should work:
> >     vos create aaa.bbb vicepmn root.afs
> >
> >     -Jeremy
> >
> >
> >     --__--__--
> >
> >
> >
>

--------------ms020706070101030702050900
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINTTCC
A8kwggMyoAMCAQICEAkp4zT/pNCLWoEO6S63nKwwDQYJKoZIhvcNAQEEBQAwgcExCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJs
aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykg
MTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTk5MDExOTAwMDAwMFoXDTA5MDExODIzNTk1
OVowgdsxDTALBgNVBAoTBEZvcmQxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS
ZWYuLExJQUIuTFREKGMpOTgxMjAwBgNVBAsTKUNsYXNzIDIgQ0EgLSBPblNpdGUgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyMS0wKwYDVQQDEyRGb3JkIE1vdG9yIENvbXBhbnkgLSBWZXJpU2ln
biBPblNpdGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMiDa8aw48w8mgJ3AGqaVdYy
/F/ki3JrZrRjFYpn36hlxA+WrEBM9nZnLIfQ+HHj4KYkeellf9KpDGdOeiJb4Na+ybriLeaE
p7BXIu91xvftq1/mIbA4Fz0jZNq+JHQwS0czSpjAw1mxfwHF9VweoPokHkwUdS1WJEQLDIVq
+YQTAgMBAAGjgaUwgaIwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEt
MTA0MBEGCWCGSAGG+EIBAQQEAwIBBjBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBwEBMCowKAYI
KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9SUEEwDwYDVR0TBAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEABpnmsPQt2gDfVegXjI6ytXBxIW/X
1wRdpWYzv/ZliJv3EYBkg3ymJpeYWhqWlKNw4ApyztW8q0w7WQQAm8eIV5qVZIDlsEUTidH2
yrM3QSR61wiSq+9RYqHagdaFGZ+35PstR9yEcgOeoC6iTZwJHYwNRZlhjGePTIaNeIjdnLMw
ggS8MIIEJaADAgECAhAhAJSFP4l7p65vZtwjlB6uMA0GCSqGSIb3DQEBBAUAMIHbMQ0wCwYD
VQQKEwRGb3JkMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13
d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU
RChjKTk4MTIwMAYDVQQLEylDbGFzcyAyIENBIC0gT25TaXRlIEluZGl2aWR1YWwgU3Vic2Ny
aWJlcjEtMCsGA1UEAxMkRm9yZCBNb3RvciBDb21wYW55IC0gVmVyaVNpZ24gT25TaXRlMB4X
DTAzMDcyOTAwMDAwMFoXDTA0MDcyODIzNTk1OVowaDENMAsGA1UEChMEZm9yZDEQMA4GA1UE
CxMHZm9yZG5hMTETMBEGA1UEAxMKUmVjaXBpZW50czEwMC4GA1UEAxMnV0pVU1RJQ0UgKHdq
dXN0aWNlLCBGb3JkIE1vdG9yIENvbXBhbnkpMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDrud0JL0bg35jIDPw+vaymW0Wm+SbpaWhV+igDcFNJUCS319e9QX8lvim/c0gkrUeul6/w
kDlGAtXiirG8TovNnQpjiFbt9lAV1JDBH9XymEMYrB80tu4M9mXPKB5nq2oJBmCokOgpbLYh
XVKPnNZ3jaNT2LJI8/8zZySu5B/ZjQIDAQABo4IB8TCCAe0wCQYDVR0TBAIwADAcBgNVHREE
FTATgRF3anVzdGljZUBmb3JkLmNvbTCCASQGA1UdIASCARswggEXMIIBEwYLYIZIAYb4RQEH
AQYwggECMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMIHS
BggrBgEFBQcCAjCBxRqBwk5PVElDRTogUHJpdmF0ZSBrZXkgbWF5IGJlIHJlY292ZXJlZCBi
eSBWZXJpU2lnbidzIGN1c3RvbWVyIHdobyBtYXkgYmUgYWJsZSB0byBkZWNyeXB0IG1lc3Nh
Z2VzIHlvdSBzZW5kIHRvIGNlcnRpZmljYXRlIGhvbGRlci4gIFVzZSBpcyBzdWJqZWN0IHRv
IHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkuMBEGCWCG
SAGG+EIBAQQEAwIHgDBbBgNVHR8EVDBSMFCgTqBMhkpodHRwOi8vb25zaXRlY3JsLnZlcmlz
aWduLmNvbS9Gb3JkTW90b3JDb21wYW55RXhjaGFuZ2VPblNpdGUvTGF0ZXN0Q1JMLmNybDAL
BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEB
BAUAA4GBAHVDFetUWXCfAKd9TRLRwfgn87HQtY89BuuxGh1xs5sPqTYiqI8vqdbW9nxwhhjn
DY/JYcSh4URBmVoOElna0cXI536fNRgBULyzKpf9xmz04Awi8mLIOW3q0JuDf2ItheDgW9xs
AgE4T6ApNRhfJC7rkyWAjV7a2J3T2/LloUKoMIIEvDCCBCWgAwIBAgIQIQCUhT+Je6eub2bc
I5QerjANBgkqhkiG9w0BAQQFADCB2zENMAsGA1UEChMERm9yZDEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEyMDAGA1UECxMpQ2xhc3MgMiBD
QSAtIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIxLTArBgNVBAMTJEZvcmQgTW90b3Ig
Q29tcGFueSAtIFZlcmlTaWduIE9uU2l0ZTAeFw0wMzA3MjkwMDAwMDBaFw0wNDA3MjgyMzU5
NTlaMGgxDTALBgNVBAoTBGZvcmQxEDAOBgNVBAsTB2ZvcmRuYTExEzARBgNVBAMTClJlY2lw
aWVudHMxMDAuBgNVBAMTJ1dKVVNUSUNFICh3anVzdGljZSwgRm9yZCBNb3RvciBDb21wYW55
KTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA67ndCS9G4N+YyAz8Pr2spltFpvkm6Wlo
VfooA3BTSVAkt9fXvUF/Jb4pv3NIJK1Hrpev8JA5RgLV4oqxvE6LzZ0KY4hW7fZQFdSQwR/V
8phDGKwfNLbuDPZlzygeZ6tqCQZgqJDoKWy2IV1Sj5zWd42jU9iySPP/M2ckruQf2Y0CAwEA
AaOCAfEwggHtMAkGA1UdEwQCMAAwHAYDVR0RBBUwE4ERd2p1c3RpY2VAZm9yZC5jb20wggEk
BgNVHSAEggEbMIIBFzCCARMGC2CGSAGG+EUBBwEGMIIBAjArBggrBgEFBQcCARYfaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjCB0gYIKwYBBQUHAgIwgcUagcJOT1RJQ0U6IFBy
aXZhdGUga2V5IG1heSBiZSByZWNvdmVyZWQgYnkgVmVyaVNpZ24ncyBjdXN0b21lciB3aG8g
bWF5IGJlIGFibGUgdG8gZGVjcnlwdCBtZXNzYWdlcyB5b3Ugc2VuZCB0byBjZXJ0aWZpY2F0
ZSBob2xkZXIuICBVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5LjARBglghkgBhvhCAQEEBAMCB4AwWwYDVR0fBFQwUjBQ
oE6gTIZKaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vRm9yZE1vdG9yQ29tcGFueUV4
Y2hhbmdlT25TaXRlL0xhdGVzdENSTC5jcmwwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQB1QxXrVFlwnwCnfU0S0cH4J/Ox
0LWPPQbrsRodcbObD6k2IqiPL6nW1vZ8cIYY5w2PyWHEoeFEQZlaDhJZ2tHFyOd+nzUYAVC8
syqX/cZs9OAMIvJiyDlt6tCbg39iLYXg4FvcbAIBOE+gKTUYXyQu65MlgI1e2tid09vy5aFC
qDGCBFgwggRUAgEBMIHwMIHbMQ0wCwYDVQQKEwRGb3JkMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB
IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MTIwMAYDVQQLEylDbGFzcyAyIENBIC0g
T25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlcjEtMCsGA1UEAxMkRm9yZCBNb3RvciBDb21w
YW55IC0gVmVyaVNpZ24gT25TaXRlAhAhAJSFP4l7p65vZtwjlB6uMAkGBSsOAwIaBQCgggK9
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxMDE5MDIz
OFowIwYJKoZIhvcNAQkEMRYEFGMS+ZmMw9gvubSBmpGDgex/Hlm0MFIGCSqGSIb3DQEJDzFF
MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgEoMIIBAQYJKwYBBAGCNxAEMYHzMIHwMIHbMQ0wCwYDVQQKEwRGb3Jk
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp
Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MTIw
MAYDVQQLEylDbGFzcyAyIENBIC0gT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlcjEtMCsG
A1UEAxMkRm9yZCBNb3RvciBDb21wYW55IC0gVmVyaVNpZ24gT25TaXRlAhAhAJSFP4l7p65v
ZtwjlB6uMIIBAwYLKoZIhvcNAQkQAgsxgfOggfAwgdsxDTALBgNVBAoTBEZvcmQxHzAdBgNV
BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20v
cmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxMjAwBgNVBAsT
KUNsYXNzIDIgQ0EgLSBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyMS0wKwYDVQQDEyRG
b3JkIE1vdG9yIENvbXBhbnkgLSBWZXJpU2lnbiBPblNpdGUCECEAlIU/iXunrm9m3COUHq4w
DQYJKoZIhvcNAQEBBQAEgYAg16+7Am7befIzEkS+4rjVngVUlYOQArgYJAmpIbGYqRDKITi7
Fd56FIYUIhzxfPrQlk1xjJnb/+ASdeKUOEX/aFouN1ze6Heh2d4GVX0NGkdf9gcAFO/meOrf
0wEV5kWEV/Rg0GrJJPS1z7Zg/O4V63srMn+SswF1ypAPZhuxCwAAAAAAAA==
--------------ms020706070101030702050900--


From rees@umich.edu  Wed Mar 10 19:11:53 2004
From: rees@umich.edu (Jim Rees)
Date: Wed, 10 Mar 2004 14:11:53 -0500
Subject: [OpenAFS] FreeBSD status?
In-Reply-To: "Kim (Dexter) Kimball", Wed, 10 Mar 2004 11:24:54 MST
Message-ID: <20040310191153.7A13E20A71@citi.umich.edu>

This isn't a patch to FreeBSD, it's a patch to OpenAFS.  No patches to
FreeBSD are needed to run the OpenAFS kernel module.

From jhutz@cmu.edu  Wed Mar 10 21:38:30 2004
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Wed, 10 Mar 2004 16:38:30 -0500
Subject: [OpenAFS] setup
In-Reply-To: 
References: 
Message-ID: <3546892704.1078954710@minbar.fac.cs.cmu.edu>


On Wednesday, March 10, 2004 10:47:12 -0500 Jeremy S Barton 
 wrote:

>
>
> On Wed, 10 Mar 2004, Mark Neal wrote:
>
>> i'm trying to set up my initial afs server. when i get to the "vos
>> create", i get a message that the partition doesn't exist on my server
>> (but it does).
>
>> command==> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth
>> what am i missing?
>
> It's not what you're missing, it's what you added, actually.  remove the /
> from /vicepmn and it should work:
> vos create aaa.bbb vicepmn root.afs


No, folks; the argument parsing in vos is more robust than that.
'/vicepmn', 'vicepmn', 'mn', and '351' all mean the same thing.

Unfortunately, you can only have partitions 0-255 (/vicepa through 
/vicepiv).  /vicepmn is not a valid partition, and will not be recognized 
by the fileserver at all.

-- Jeffrey T. Hutzelman (N3NHS) 
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


From Bdcneal@budget.state.ny.us  Wed Mar 10 21:42:08 2004
From: Bdcneal@budget.state.ny.us (Mark Neal)
Date: Wed, 10 Mar 2004 16:42:08 -0500
Subject: [OpenAFS] setup
Message-ID: 

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_406142AC.63026678
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

i can't believe what an idiot i am. you're absolutely right. funny how i =
changed it to /vicepa and it works. sorry everyone.
=20
Mark Neal
System Administrator - Web Services
NYS Division of Budget
(518) 402-4181
=20


>>> Jeffrey Hutzelman  03/10/04 04:38PM >>>


On Wednesday, March 10, 2004 10:47:12 -0500 Jeremy S Barton=20
 wrote:

>
>
> On Wed, 10 Mar 2004, Mark Neal wrote:
>
>> i'm trying to set up my initial afs server. when i get to the "vos
>> create", i get a message that the partition doesn't exist on my server
>> (but it does).
>
>> command=3D=3D> ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth
>> what am i missing?
>
> It's not what you're missing, it's what you added, actually.  remove the =
/
> from /vicepmn and it should work:
> vos create aaa.bbb vicepmn root.afs


No, folks; the argument parsing in vos is more robust than that.
'/vicepmn', 'vicepmn', 'mn', and '351' all mean the same thing.

Unfortunately, you can only have partitions 0-255 (/vicepa through=20
/vicepiv).  /vicepmn is not a valid partition, and will not be recognized=
=20
by the fileserver at all.

-- Jeffrey T. Hutzelman (N3NHS) 
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org=20
https://lists.openafs.org/mailman/listinfo/openafs-info=20



--=_406142AC.63026678
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML






i can't believe what an idiot i am. you're = absolutely=20 right. funny how i changed it to /vicepa and it works. sorry everyone.
 
Mark Neal
System Administrator - Web Services
NYS Division = of=20 Budget
(518) 402-4181
 


>>> Jeffrey Hutzelman <jhutz@cmu.edu> = 03/10/04=20 04:38PM >>>


On Wednesday, March 10, 2004 10:47:12 = -0500=20 Jeremy S Barton
<bartonjs@cs.rose-hulman.edu>=20 wrote:

>
>
> On Wed, 10 Mar 2004, Mark Neal=20 wrote:
>
>> i'm trying to set up my initial afs server. = when i=20 get to the "vos
>> create", i get a message that the partition = doesn't=20 exist on my server
>> (but it does).
>
>> = command=3D=3D>=20 ./vos create aaa.bbb /vicepmn root.afs -cell ccc -noauth
>> what = am i=20 missing?
>
> It's not what you're missing, it's what you = added,=20 actually.  remove the /
> from /vicepmn and it should work:
&= gt;=20 vos create aaa.bbb vicepmn root.afs


No, folks; the argument = parsing=20 in vos is more robust than that.
'/vicepmn', 'vicepmn', 'mn', and '351' = all=20 mean the same thing.

Unfortunately, you can only have partitions = 0-255=20 (/vicepa through
/vicepiv).  /vicepmn is not a valid partition, = and=20 will not be recognized
by the fileserver at all.

-- Jeffrey = T.=20 Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research = Systems=20 Programmer
   School of Computer Science - Research = Computing=20 Facility
   Carnegie Mellon University - Pittsburgh,=20 PA

_______________________________________________
OpenAFS-info= =20 mailing list
OpenAFS-info@openafs.org
https://li= sts.openafs.org/mailman/listinfo/openafs-info
--=_406142AC.63026678-- From james@JamesSchmidt.Com Wed Mar 10 22:37:47 2004 From: james@JamesSchmidt.Com (James Schmidt) Date: Wed, 10 Mar 2004 16:37:47 -0600 (CST) Subject: [OpenAFS] Stupid question #2 Message-ID: <20040310163431.L75167@speedy.insekure.com> As always I've made every attempt to solve this issue myself before resorting to posting to the list, so here goes. Is there any way to prevent the RW volume from showing up on the clients? On the client, if I do a "ls -al /afs", I do not want any ".volumes" to list, only the RO volumes. I've fooled with ACL and protection database settings but it seems I can only get all-or-none results. Am I missing something? Like last time it's probably something simple and stupid I'm overlooking, but I can't find it. Again thanks in advance, James From tim@umbc.edu Wed Mar 10 23:59:45 2004 From: tim@umbc.edu (Tim C.) Date: Wed, 10 Mar 2004 18:59:45 -0500 (EST) Subject: [OpenAFS] Stupid question #2 In-Reply-To: <20040310163431.L75167@speedy.insekure.com> References: <20040310163431.L75167@speedy.insekure.com> Message-ID: > Is there any way to prevent the RW volume from showing up on the clients? > > On the client, if I do a "ls -al /afs", I do not want any ".volumes" to > list, only the RO volumes. I've fooled with ACL and protection database > settings but it seems I can only get all-or-none results. > > Am I missing something? Like last time it's probably something simple > and stupid I'm overlooking, but I can't find it. > I can't think of any simple way to do it. One way to do it though is to create a seperate root volume containing just what you want in it(hence no RW mounts). So you create something like root.afs.simple, and then add the option "-rootvol root.afs.simple" to your startup scripts on the clients. Tim ----------------------------------------------------------------------- Tim Craig These are my opinions and not my employers. :) OIT-Systems tim@umbc.edu It's hard to be serious when you're naked. - Garfield ----------------------------------------------------------------------- From gug.ml@laposte.net Thu Mar 11 09:18:54 2004 From: gug.ml@laposte.net (gug.ml) Date: Thu, 11 Mar 2004 10:18:54 +0100 Subject: [OpenAFS] OpenAFS and LDAP Message-ID: >Yes it can be done without Kerberos and use X509 certificates >and TLS.= GSI implements a GSSAPI mechanism that uses X509 >certificates and TLS= to authenticate. The gssklog program on the >client uses the gssapi to= authenticate to the gssklogd running on >the AFS database servers. Th= e gssklogd returns an AFS token to the >client. >gssklog can be used= with any GSSAPI SO if you have so other >implementation it should work.= It also works with Kerberos GSSAPI >implementations such as MIT, Heimda= l, SEAM and Microsoft SSPI. >And it runs on Windows. >So with AFS yo= u don't need a kaserver, but still need the PTS >or some replacement for= it. The AFS token is still Kerberos, but the >user never sees this, on= ly the gssklog program which passes it off >to the kernel. >In effe= ct the gssklogd is issuing AFS tokens which are in effect >Kerberos >ti= ckets used internally by AFS only. Thank you, i will see ... Have= you see an implementation to use with ldap ... because at ftp://achille= s.ctd.anl.gov/pub/DEE/README.GSSKLOG , we can use kerberos but not ldap = ... thx in advance =0A=0AAcc=E9dez au courrier =E9lectronique de La P= oste : www.laposte.net ; =0A3615 LAPOSTENET (0,34=80/mn) ; t=E9l : 08 92 = 68 13 50 (0,34=80/mn)=0A=0A From pgunn@cs.cmu.edu Thu Mar 11 15:51:59 2004 From: pgunn@cs.cmu.edu (Pat Gunn) Date: Thu, 11 Mar 2004 10:51:59 -0500 (EST) Subject: [OpenAFS] Problems with OpenAFS kerberos Message-ID: Hello, I'm in an AFS/Linux environment, and am using the Kerberos that's part of OpenAFS to handle authentication. So far, it's worked well for most users.. To set it up, I replaced /etc/pam.d/system-auth with this: auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok debug auth sufficient /lib/security/pam_krb5.so use_first_pass debug addressless auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so debug account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/pam_krb5.so password required /lib/security/pam_cracklib.so retry=3 type= password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow debug password sufficient /lib/security/pam_krb5.so use_authtok debug addressless password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so debug session optional /lib/security/pam_krb5.so debug addressless I set the cell in /usr/vice/etc, and made the local modifications to /etc/krb5.conf, I made accounts in /etc/passwd for all the users, leaving /etc/shadow alone. The two relevant accounts are: pgunn:x:10280:500:Pat Gunn,NSH 3125,,:/home/pgunn:/bin/bash censored:x:7675:10735:Censored:/afs/cs/user/censored:/bin/bash Unfortunately, I can SSH in, he cannot, and we're certain it's not a password problem. He can get in via ssh-keys, but not his AFS/Krb password, although once he does get in, he can klog. Here's the logs from /var/log/secure of me logging in: Mar 11 10:14:35 logo sshd[6025]: Accepted password for pgunn from 128.2.222.44 port 53336 ssh2 Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: default/local realm 'CS.CMU.EDU' Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: configured realm 'CS.CMU.EDU' Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: flags: addressless forwardable Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: flag: user_check Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: flag: krb4_convert Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: flag: warn Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: ticket lifetime: 36000 Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: renewable lifetime: 36000 Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: banner: Kerberos 5 Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: ccache dir: /tmp Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: keytab: /etc/krb5.keytab Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: called to update credentials for 'pgunn' Mar 11 10:14:35 logo sshd[6027]: pam_krb5[6027]: _pam_krb5_sly_refresh returning 0 (Success) And the logs of him failing to: Mar 11 10:09:44 logo sshd[5911]: Accepted password for censored from 128.2.222.44 port 53258 s sh2 Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: default/local realm 'CS.CMU.EDU' Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: configured realm 'CS.CMU.EDU' Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: flags: addressless forwardable Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: flag: user_check Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: flag: krb4_convert Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: flag: warn Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: ticket lifetime: 36000 Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: renewable lifetime: 36000 Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: banner: Kerberos 5 Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: ccache dir: /tmp Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: keytab: /etc/krb5.keytab Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: called to update credentials for 'censored' Mar 11 10:09:44 logo sshd[5913]: pam_krb5[5913]: _pam_krb5_sly_refresh returning 0 (Success) Mar 11 10:09:44 logo sshd[5913]: fatal: PAM setcred failed[3]: Error in service module For those interested, this is using OpenAFS 1.2.10 (from the official RPMs) on Redhat Fedora 1.0 He is able to log in on our Redhat 9 systems (running OpenAFS 1.2.9). Any help I might get in debugging this, or areas to poke at further, would be greatly appreciated. Thanks. -- Pat Gunn Research/Systems Programmer, Auton Group, CMU From shadow@dementia.org Thu Mar 11 16:17:19 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 11 Mar 2004 11:17:19 -0500 (EST) Subject: [OpenAFS] Problems with OpenAFS kerberos In-Reply-To: References: Message-ID: On Thu, 11 Mar 2004, Pat Gunn wrote: > I'm in an AFS/Linux environment, and am using the Kerberos that's > part of OpenAFS to handle authentication. You are? > auth sufficient /lib/security/pam_krb5.so use_first_pass debug addressless pam_krb5.so didn't come from us, and CS.CMU.EDU isn't running a kaserver (good thing, since the kaserver doesn't do krb5) > Mar 11 10:09:44 logo sshd[5913]: fatal: PAM setcred failed[3]: Error in service module strace it and see what happens? From schulz@iwrmm.math.uni-karlsruhe.de Thu Mar 11 20:09:32 2004 From: schulz@iwrmm.math.uni-karlsruhe.de (schulz@iwrmm.math.uni-karlsruhe.de) Date: Thu, 11 Mar 2004 15:09:32 -0500 Subject: [OpenAFS] Hokki =) Message-ID: ----------xxwxigojuiphjiwasxvu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Looking forward for a response :P ..btw, "13247" is a password for archive ----------xxwxigojuiphjiwasxvu Content-Type: application/octet-stream; name="AttachedDocument.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="AttachedDocument.zip" UEsDBAoAAQAAAOB2azBHeaShHFQAABBUAAALAAAAYmtsaGJqZC5zY3IUmXImmT2qexScp2T+ XFgkF+OrGxVsfV4kgLsD1eTnT/I27RQpOspECMcRj2gmC/F0dT2CqYwM+AoIKq6IPRac6QUp n6Q8YRRikhgotSLCpagL/2VKnckYyl8o/vo+aUR0gE3QxHFZ8faFIwqhCuE43/hL6kp5oKGU pwFXW4d4RvaJ8vYf0T/UXTDUFBugU9Ik+XiuMUHEvtlWs7tlWXoZfDEyyOh1eMv1yiDxUiTd hjI073OLJBHSN7eZlmWOqmpAx6N/loMXKyQZCvN2uKSl7xoS2gc8ihWF0BH+06OHKZJxMRST 7DHGDEefgZ7p281PlYyrrGA6eO+bbn9f5VvhjSafUft/4s7/XnCQsXi2/tmjjW4zOfFLtRKb 9LJMWJg2L/9vc8D1uRouYu+3uHfs5jqwNaiimulHYm6TRgGaodg+evfHqiqAaRBetjyA9YUu CfNTa60yTHsDdRPUw/Vk4ZEQf9pib0dOxGehbSO1hse9Xc2aXx37qXon4d9sEIK23W41b7sq EGaNoTdtQSB/Uh1RCUid+snVDRrbpYKz73nlXSKbYAhLOPBGpVe96tbm7cgB9JUMQfXa3ngr 1OMmsqD7FiGOX5LiRxLeQHnwk8VamGaNHz77pfPB30yQUAUoE+MVz9Qm/EdsZ7wsWjFpCGcG FF8oeJq7qeM/vwWfsRXZXugG6sBhEdCqe2iCsz0CcsD5oE9XO7WQTi34qVviaoldFKj5zGZp yyIi/hpEiiayuMryckGeQHPr3WqOrpbROCdfywxobFaXiY5gGGdN4gTBs/jov/Y0UztHUjYy sp2cDxh7XkW4ac4D6nmNUMh3LNoMelF9lY0ekCkgbJOlhK6VbfcmHrhiCZFGOgQY6QDg4Xp4 AiPUBUIf6qnbqtTCxo/EKiXUfXupLhpWERxerdO/PrwM0CL5ef5oQ2Sk0/AreAV5zlkxFslK c+2/S2uZSNX43gLs56WHqVJsOqMFrdGGiKc3PfrNz1jYWBXBsfmCsJbaeMlGGtk3RMfgafVP V+ljAw8hVcoy1C0U0qjOLA+rmT5TRusn8RxGar6RRclzwqdwsG5Zyh9Pandavz/dAOVf1alP kRjIiZ2LMKgzsK0mDbZNo26+khmDfTOROwca6m7nQO0vH9Z5Bd8iXzOcKRjkEhKerw5DxDpg nIJVt+RC8uKA4eaH/h6imlKDGKbGxf2a7u8E+woD9qHxN+G+KaAKpgOiT8EENFE3d2aIqBuh XnzlnineVL+FIxDkmRJwDksAzvTk1VQZh0To/sz1ZsVAaQfsSBKC6TfPSmv68l740D572FCj 22IURFDBp+A+dfXhdcagU+5oCfjQzL73Z45nlNii5nblFZ6PCtHG9up1UnyQPbN19X8O+eFA NhfubN824QiGjG+bIF4RIm0ppJS4O5lytgWOkY4SWutuBR56VWi7Xriujf74CQzPvH8tbx39 M8Svf0L4Vw6p/vqGJKa1k7l6vcwTydTkAfLXDv7v1EmVMRMTuChv47ckroWl8yl5wleVbpXA XYOvJL3+f8ZrnNEznJVA7Tn0D+ahoffENVLQEDDWpOExvGM5oIhGST/jEkCVvP3XkrzlFIFd K7Kd8rjosd4dy53GR+T/LsQVlvMjLXW9xombN489cdkCAi6tBEltRtTEkOzsHZTWnHeFmApr ali+gKtymgLQAIgsuAC5aPn+Vaqf6EGphOezKeFZIRh2apfSFb3g1GtQ22mHQZdu+UWheMU2 WsILUvKAkXi8DN7qUitzXB0yoew4SvMEXZ18FbFqR/vMX6ovt+O5Z2mqwQ175BEBQa+LJ9NB 3/gHzFkq/g27/EC3Nl6Wjs8yKpFNV0wSyh8OwAoJOgiLztlhNPzh7RctniCeq4E37bUyWJW3 svkVVHeY7ze28iURDvIxaPvmitOj/DC0JDkTLqB+16cR38dv/y4zM5BjoCi3Z1m3XHNjxudU MMY+4do7AOAPo2MSxNORLpBFBhjr8/mBvXcaS2VRUcCkfnsrg3Rp5YlQHXF9vgMl72YQf6hB l7pCHCOt2MUO/FIvxPIj+L8e/xFSSPfAjOnRg84B0BZXuvIyuESnIdm4VdKpkCOwoseyDGdd ZzM1laIEv6NFOI+80dhlD6FRdgladbx30d/NCZjITJcg/2CqnXNHxAhrkj/D6t+rbUwBUheZ ZpOVDWQyd/pMY+enO7onysj3EgCyxNjhkHgKc9lZH2dBRXV2No1ZTWctiYbOOiVXpVwIDAV9 jDdX8Pt04rMn8WfZR80IHjhkQROZvKy8plB5yfuYQma/JR3zzBWqKBCds8STgCH48Trfqw/R 0qryDTZOb/Ba19/CyRb7oqaj/NZIkROLO4Oj+D0kOev0DKhp16jtcXYOExy1d8C75Ce2fO9I 4XTkraVaKgWFPHJ35ycHfldfXbVmkYpMPlc/+bl9798VcSyzTCRMQ1EYRh5V6aFuOFT+iSKT jAjPdG5fKXwjaEzm8fW76mGO7tdUSKaYiNHaORBOdrRSHYPCRCUm8Ir3zrip84DxzRWrZX+D 6jCAsMsV/zteeR1l+iWDMm7kbO9536d5I8gTdJ6Dmr/F3gHmokkULnfTzeMNU9tUjcYkKC+4 uTNXmxYjt50r45lzHgXyyQlUo+W+Ng4jZsLoHdTbUGlEFKmCHRKEDnvYwi0S0anN0uWYltlx Ky+abHmihYmSEJRXaKVsvzaGTiXjyGWdFYl7xCm+TgIXwzQpuDHL9mOBcm689mw9Rc14BPsR PJM+9ymR6f6u202EWZ5Bwvvu1/vL9qdRwz2drLzdhmrwrLOIT6iFDlXuRIUn+Zwk405wXzzo /TM7JWNz4MLdnjhKcsC+y5YrwmsxLBdrDEAtXe72HvDZEd4Lg0wgpuPgqG6iTwCiWwmJ8IMJ VjSzfwCMqWCa+Iv+zHseQmMAwNDJucd/O0Aw/mBv8uG958W5yxasDIcecjcV7cAukhDcAZnT h3q5FOJN1YX2fP2xGe8c0jKqzcCqBc5tzIVUM8Ms3kR89qLMFJUSawOE2qS7f4VPzW/SVZvV +RZpioo4xvY4iYFYgL7GclET+BUkLlbPBq4W0Olg1DNKrAd9C+fqfLD4qPbEiuk484AfMBes fVMSv77Vhj6UpWknOdVd+uYs7wiNGyGTF28Fhx3cSIbZbg21UtSqZlTG8WP7J6gL1LcO9ync 1dM5bvXlGac4fGgmgmrgZr6MaQy99XPWikFtJvJP6Zbdapx3g5CT99FJ18FhT0qKZqGnl+e8 qS7S8U1hheFT7amihWH6IZClghe8qqoaxt74FH3ybTtM7TCMqSnpfeuj1xSk5RsRxMbFmS13 VQtdSR9Kg/o47yxmJUG6Nub/PhH0paVELR86ciRIneaFkHddRCczxrD4fMimzf0JBuu049uK CQkpJX4TFYHDMAuZisXsFW6wHBjl9eiBbsVN/FZ/cceg4KmKosL5LZQ7wdTViKlcXMdmALUY RXp69caP5q4CyxHD/NyWoSV7xLveHGJedzQEjEa4T7zbY/484tPkaf/h/65niH48yl7xpHcj /EiPxU3Tk2A/HQ61XJcAeOqPvNng50xIOP/vRy1vTIQMSxhOWaEA8Y8ItM1kynP9FrbHlkC7 TaJTJGJwD5wizUvR6/hRZmgZkevduGtgtlvm1rbz/Dya7ZHITQ8e3ckSB7xyBFloLfoPH/9M 5XhMlTfe2UB5ih3ex3WzpttegnCKxn/9ons2CbEHrfhzGYwUDJknQN5MZOQnFEmCiWmTeTYc O1SfewZdMm/UjhedUmXu68TNUMtEY+T5flSmE9gjuCqNIWC502GbqfFsuQeKbRMizPOggw5a 7Ynkd24H6cg8ZaZqR3g5cgJlG+n3Rlc+hr+lGxMQBTeh3K6U05aU4wVmwXousaFr+U+17v4I 1O+p2Rg3BpWQPB3hTn3PJVUXjmrHvx9APRnN1gLb5ruxIlATwvt5giZj3KID8QzF3u/da4jx xjwJiCHoWhBwHbdVMM4Zvkord/j71Xum+7UoeqzwqOwG664303jVHFnZJsT1TiGzD8T4Bqty w0XKOTRnklhQJBj/f4ezY++ipGW6crlTtweTx22hgDedqkQOSKXsUizdUTqldvH5uZbxNHFQ xDDmYn8HLEEas26hZVTbot1cS2Kavjgrzk+rvgP765tbl1iaZHse50QiGYMwgpJtroojtayh BSrYoxJGAvcJCAG4L83BMQ4+DLxtX0xtR/bmo9VjRF73KQaJzZDxL01EvdgurfUFS5YRLXrr +VJzKDsvlBaBcrd6838otQ7RIJ1NQ2rFaWNcOneTHQrHp5W9OvnU7MTcZS3yJipMETludRSJ EqwJHGAxNYKjf/UZXNTvhYsUuDukDd8jrtsrfSqWd6f2VJYDlMid4GJQK7kqa8gmJqLbvmrm yC2hwcUzzeyUGKe4AJeTotnr6OxNcID1wh6iLBCLcjF0SoMj04bsSAxKuHfv3hmCiV+Pmss6 D8KpixXhtV3hW/sy/Ixc+P+Gn+44Ts+XBGfdyWaybq7MfxgXZkBc/kLphcNNaHqhtCeO3Ba+ mQG5um6bsjlHD8MXZNh2WqzGQW4ydS5W28/yjq3pIz7FL7v6sFYArpTl7YX5KXlmQOQe5NA0 b7rr3CPTWJhsGducEhLmPK/EJsaW9qYp+RQIbs9vfX9EK/AS8mdcqrH5usHKcu3oLiX7D063 06PyhKz4JvyoN/WtNetAaw8YuoZzbqo03HHr/0DvKY5Ea21cpvAaRPDXsHGGeM1IAReux12u ydFNI+U2Fr7TKL0cmENoQpCKxwY3reP7S3sb6LrsSOevdzdMeAzNQ9v5BOqGla4JqG/IR6Nm YvxASVgP6rmNwLmC1Gpllycz/vCyoglUuy5GZsmPcSiJaO7lKXTXuojfsI22VJm7OXOuwUIB 6AYN5Qb/ZigUhciFxL4SpoYajT630o5YuQ2b5VZD3Ta8wKRUnbhH5kiD43wy1UsmIA1BQ5HQ nxpM4OBfaIqVhh9WIPG1JxuMblOLndjfMDqB3oN05ziAcAlDfeasm+VwvQKx7XlqoBMHCPne AdydmSzP/ouKfOsjRA/nBfpf8dMiZkjwKyVIVSPwfdBOcnW6lfcQmheTWpop07JfDhA/zyfW ++s/XMeCmTRRhTOk+7MQLcIsnaVFK8i/pS8C6vgFnC2Lzyk3XtUzNIFO5KDf0wfKaWIzBcZo PeaYtqnzDJQA5NpIgL6dIT2K92wnPvN6eLQVe2IGn7NW9fB7OJeAB9MbxDVgGpBsgrUpARqO mDMKVnvqapbkjWnSmqQOWzkDFYRCUxLjikj9KT9w2rAST6kQsl/TqYY/65P5SYci/9W74gM6 MsAsS2TqJirMS5HbSX0v77CkbDIRfPS+GbQui2SYy/bzRheJA0ZwLbQz44d/JQH/VpwjBu8Z BYK/HJ7wQfQjp+YkLRmfFZr+ZEb2qAW6pgwVk6eKf+reD96pV2vhz0G36w9D6urzMWgIReuf oBbrLiCy0mlyrR7ODmGagpop980dmb85fehrs++cTfB3T/gn7xhPoEXThfM/C7ujoLSQNRgX mB2Tb0X2ZoN4+2Hg9tq8MBrqWB8ebFFxKsb1wQ8PaLYEHCXcIFSZYf/defNkFRd1kyzETQq3 eY2Gmjf4sNH2QgPZfvrwEVAQrUb95uFZ0q8Ul45l/6Oj3Ge1yCjGgKJW00BosAiR2ZSKovBZ 9iiy96nlPnC4q+uf309+fArIsug99JAguN+XaqkIdJ+oultJGm+zy+KdLN8mspfjV56u35A4 Jzw6IHaavIE+WSFj0RcvuQrUh1zjbRccEXx0WxMkExTbCiudjBnizccapWrhAcQkiHSxLYIP WES9K2gGAqvbuzgYwPMGcycSvKmchviuZ5KNOh2cOwNyyMleTxUout5HXP/dYgNwj4fikJcD +HqXmCXidBKvVi1ys5jfhAqhZKOodKRn2/BHb6WaGGH3bhPJ2ul4DApx8TNA0LQGuBi9C3zs MK7M+YaaSfqrmM5Em1ZRAgiOE23CgJG5HtpNgMgMdGvyTyNv63cnZybF8aO9ANUqnioojUgh WlPnDHv1mi4vwTbMjEDg2jI9c1o5yAWCCkVlmWQ3zDGVAWL0uK3kU71/0e9Tk6zHGNH49oqD Fu5gJSIZAINw2bLKw4cgUn7ECAw7sOF5ZJWCWhysIzm0NmpXegV2CtZIIC1WOdQkkZ1Q2euJ JNYXBXRlMkpBrnGnrpTN16TMDwB//lPGdlVqANiFcqW0TpdSyRWNydXoDGyZzTANv3u0icwg MW9C7ShC6pUlpTf1MgfV9S8CwPX8Zk/Mq8pacVtsM8cvWH/ZgNqpKuwhZyaN2WH+EbnOsl7D spaHjYu4ONAyifKPkScAEFjIsRE+zikJpctUPpDy1K/ettN2hVwJ+VlLrMraZDfuVHY5k8O+ VGGOLR7CCdJ9tFzntXd53Nb4Rk1v4snAlLpS+i1Bbmp9CCOwDZy1cCqkg+fxwz66jVDcK8JV VnH8DtmXdIiZS4eHzXQlmFXcdF34xGINxFeZECtDDWiG7CX1aGZduY9U3D23+qqBbTiyhs4K J2NuTBBOimub4KaCnd5r1W22VcSidbBkyZWeZLUtaz3DehEYBEP6zMJtmZLDNcicPr/I/yO1 +n32ask9rkM2ksdY/embXEJySsj/oGC8FHOI/0o7c8+7dzfyYwq/rv4qCHkn1be+Tud64bOW CiAeSAGP22wbFUnIuPZ/xsZA4FnnC8qxuwTCMv3P/gAuguvcqrX9nG6SWtDb0dl0WntgT3Z1 08KcDqbS+yzVwCjq8AH7BA25OceunonJXLeZIhkw5Q+cxrn2xHjbSqZVWfLSdQamWsujEQKz QsfUImd7ver1KadiYGOsQbL6Bem2R7jreR4LiXOvCSysI+Uk5ZDBVVJEuFYgoC5awynunSCn SteoMV5kxF+HVdTnl+6EdEER1Y/epfCwBJSVUfUpbv/O8l7Lwf2M7hLEy+gQVoUogRvoIJCP bwL6/NtiYR+2ZoIhdxP0mTBg4D0UHzZXzwQx/LauwBhEMY6ue124vvqF4Lis8QCJIYKRGQdD 45hx13lZwgxvTMTZiyZWlmA3tI4DdxUb9ez/6C7tdSbcusdhMeJ7uIfnjXjJW2bSRIeHsZI5 7gBGrWvGkb8Upia63V9bwyJNuoYGuZ2rlAW5JnYuxmc8qXr+PIBTE3xBboDoBPOZ5NUQKJTM 0uxYJlq3e/e0iB+Vsm5cweuvtmq3L+b1ziQYox69XWU0+su+GpSvEDJ6EXpwTIsBMrlu8RI8 Bx88+gD+33R9UZMPWRLr/KQNPirhjn4YmsaGdFTVfxBBGbXlgSua6O1HXkF7JH5bkyQeOn5E SFOps5SbWGQZTGyE5xfD2pS+uG7jSqxd3gaPzhBU13VC69tubv+K7KmxikKSL88j3hFwS2k0 iB9YjOcstoZVRJZKfAK3uf8owT/fJL9ve9nFDE050GvPh2WzZ4Zgm12kC1wJ6K+1IdIykkKK lqc6tUU21GeuvFbG2jyHt7wTJoMGsuPxu9Y7jr52d47VjKLdF2Sy+ttMKp4jEjFbjgQ0vONE JFeCfpGHrSEHscnAXlWnHFY49NJPXgZjyLs4DmvC6V6sdjia/n1eElO8Vhcf8eAlmqaQ21Xv ZeKzQ/UEhje3J2xaQ6j30RTY2w3cBiEiOTPWEbEJywlmRhJ+nAux5+bmgcefLXXXr2YcSDH7 5OwwYIIMNze/L0JPW5CKAt6OBEsDVD/QsidSoPlpBi+uuSmJpolXsG1F8PtGFy+Tzf1Ep7zo 9lbKq8kTrNnAIHJpJafXd7AmxhYBC2S1qbrfL/tCV/j//+E4KKunjzQ4D9Wfi0vlMTPJm3mB J/LOE8NmI/tMIvf/Rm0umiW7I+c4vac8/vGel+TxTC7q3vhBiJw42iMkXpy6GjOoy0ChVmu4 S7+l1UVntKP6jMLK9x/HT/5LFso6ho04xZppEyQ/IR1frCd3SYPiyS4jT5ou9R1Tr4cgj+o5 o2q2CtI9GKIA0Nie8Q+ls8EJsPGKmRCX0jCofQqlpBqzoOHJJ5R+qSsPjeBHc6ly5aQxiBun 0TqJnQVacO5t+AYYbXxSjEDXpADJjs89HpalCV+Sse6TukHpXwKPkqyVGUIEdSWW/zS1xMwX yjkQ9HI3HT/L8rgpdEY7ajS4aftnxe/bMLDQrdzPSp06hYFdPr+F2rw0sdEH+LXm3lcbQYM8 6KqTdqDBL48/6tujrf3ihb8si8vQp9t8EaKUK+CHD9ucZs1YF0LLdySrhIfVjsvWpbTMtlHl Ap8llQXBwWRllKvht92cgmiZ7uCQrIHj+dJKxPsDsOXVBHi2fAE31ivIGtcJl+jEi3M1lqJY /CZ6fJ8fcBznVGVKU4g7fOJuFCVydTCmK2uFd+Glf3J6f4WafGigW0LrISXLhj7iZetnrI7k 3CzfcPphOPrn6wLwfdk9c1U80m8O/+k3tSa8Z0MNGdc0ovE/e5MyAOXAx/BHX5UPncohCVdE kq1M7Efx9YkyZpQknLskURAjqfZ8J/K8qEYkEMsjfWuZ9zPYJ4OmxONCfw5Yr64OEHWRgSu6 1fEkDEAlJAEeSywKHGIft10yg9/66bVsey7JKL79Mjqe1zJA/bl+UD+Y8g0ly3Me/ldAMvyD 0EfaoXLtqxKbhPXdqdYxWr4rCUXReAJ/u37yu4VG+KocqBCNXa/BJ7EsBJvI7zJX74JrlEQL lwh5zg0ha5iKwOhYq+gCX3pjJi9pbYFfSrbe347EUD9VE7dYvpjL0fCv85WoYl0pDnHsEL76 EUxVpLAU9d5K5JMdt65TE8+CUj7V2IinlK92lCVmhngzE/58v4hPJYvaxmJAaNpBg+QmIBJu joOkJXu0J4SMm8slKK4JwAzQ4uEmrV+MxPijFJLn6gVsRMhusyMOupSROnj1t3cLnLHL3DV3 xFREAtomTFrHWrCqyCb5JEG9uGWFkKFuVx79+LVat+rAOLQ3FzCgs+PQIED8Z2OtJU+6BeBY gewjpUc7+zW1+g3ClLBJKUo3JjJaoKi1QQQj6s/RoP7XcfYdos/7EqiFKTBSwYimkFL8WNx0 8usEBqGHXc/SblVF9iQx0lVU06sJ4MR1zA9QqEuYWA8Ik6eCP6zaPE94YgIJV1K4SlyII5DC D1E/CZCLjw6yVRd5V7qTksRJftTeOdlSmYCcnhb3cK0af6cmOhBuI0AHUVUP99ntQXbe+oeD odSKOYNG1SIyYO5fzzYkPBnG8Yd1mrCBAWFfBXkDGlEle4Z2MQt7/ePSLDIq8u+S1uN7RDKP 6EbLLkz66YVfvMLr/Q6sO3KAwMIerWPE8WSPtj3HSlWOEoOQwa2Zqc8l7YXKVb9UOVuqIz+4 swARrTmVZF+fGY+NtIicJZzQqrkucTc9xyZToEmLvg6SLI070tLaBGhYdzccB+vHwCO8ECsS iZkVxYj0/A90RNag8PP2iCRabzVR9iMSV1EaCF8ZoM8ql8b4oUd8p8DbRITapK7dZcC1CnsG 30Q3My8KmZBzM+lCzmXka9Vd0ZpbOqXVF2FkTvbQIv6f3DLq9wnD3d4G7fj7O5ae00ISoc8I n4raKxU4CSR1SPdcxrxPcD0SKOMOn7SJ47kKd8uH2woF0cPX4sDS6ya6qEJOMBwvwIdKGbfp /mO2e3ELpz/iIz44HDs/pmK09WbWl/+W9SblEZbNemzW6DIvMIvQfKpDzQK0p3ENLStOnmMa HVHhjtwoUFqxmOmLj9F4sk7qSRH9sDNr3fejsJpsMh5pZQC3Le6BLKAuXjI/HzdcUr2NDVGB z3aLyX/7lfizaJ1ekaenGeWn0suaFWKnbyEV/uKNcuQCd3koc75HvOF9Yr69R6GjxMR2kH59 NtSdHvM3xHtvEs+Ato/ppOHfnpQB7loDYq9BAKUVeGmEgqBqe3ErYUQeJOcpQRw89M9i35iw hSJ9c7arr6zr4LngqlpXoEav9lXOA9jqfqqgRwHNRSLR1k9tOM2AEBMS6OjvqgkKaQ3ww4ER C3/o1jtqKx7lIvsAcZfPua8atZHwXMFDev/i5d7K6AhRLt6yYuIIbDOiklb9hlkOZavP+c/D VMdEMKobJFj0WTzY+bGvFrBe2WGX0jjC2xjJcHsgs2q0wpTUS8eNPI0un+whRSpFBaSZXDIF Od7WRlyIDyDxwhLYQUARIh7aBbLtU0ULw3yaLbH+8UozMSeGUHYRcSC9LntxW6cJnYrDl186 y2iD2GmL/jqN+ar/WaxFbuBF9gvy7EccG2r3YndzipN+pNIsnaEaeHJt3qm79n1pPKoRXzIQ HeES/WeYD+z6AojFry7qFL8pLCk0uNIqDF+FvbX9S5k4tlKBhsbTBFYp2Ni/q/Q7WKPPsqfI m8MYt6XfUvLAyU+sS41mCLs/Eded8bzJFtXnBqxeAnCxpQiTXS0aYznq0EnIYRbXzpE/QlfO UBvwN79mAp9+RjuVtyKoxTLBoFlI24sAX72LgF7lgUpAeavsjgBcKSdliaJL0lNfT4q0NoJw P0Nn6Vi5D5hQTNVSVmDAUeUKUOQNklagCu98BVxMR/qo4NpKQm9SLssWx99KHVc+W5MDuwCu 0PYRhxr19N/yYNvKcF8cWD8p3RGoWsmvZG+oaC85TniWxELWEnkFGti+5UrG0+fSSr1fJ77G 05VhOqFRLV+9Ywn+X0C2VfPFaDaSYg8BVO3xCLAFFVCWnFUN3MliZ9bA0CZHdHLyIxq9e26y 9tQpyn7SAWdHRg7+eB7Cuu4Oj7oN/78SnhaddZrhirIrcGq1nv4zREKW0hhZTQQowNjqZ2fz 7CD5Xfj9Ml8gZlbsdAKUOsXj2j4TC06vp0R8w6s72MjQYmXMVFGf7K+5eRI+lSYinopTwN8C 23FcnR+QGZxzwhe0WnBXUQPbjbbt8IzIc28crGYXAQ5jyk6hcE187UAaXqXh4LwDcMIs3egm NIf2TKIz2ndpQ/bSchGhhJ+a6yO8WbXT53k5rs1bzKao6j4EDqvqs/k82mhR8UROv9apCutk aD1FEztVyf5MFuLKJ69uvilONimtsIz5ttl0kl/pTJljJ2wVT2lQKjb6/pXJPBhCSYQ4j+pO 2r2Tw6znuRF54VgJl6ls07lCO0wXvZa+VJ2SUr32qd/AzuUeJBY0DsnUy1DSxDtoc5ylb9fL F3ITqQ4r7EQUc0jNeUE1b8cgVqpnR8983C8DEmO2dW32gsoaWUk/oUzTeyPh0Ut+n0qEmoYv m4lFlHtBfP0mRIM6KcMNEqQVqVIPdmKLc3H1FxZypdWh4cvA4JdaQhacqyKuUzZwyf/GGAsu 7upuWPeoIa0rBfBNxVhcYDziO9k1HVpnC6wx9y9KqFBmmAdDSvKazHNO2ML+nvmyHYwDFn2B JdYRH2hLv8UJFDATzBXUqlSRCO4OMWJs2rYyFMWZk4rerwUytIc5WhOwhr6jLvD5MzborOnx ESN/JuhJo7sM1ZOmqZvH0ky+DVP8XrPLufPXG+aaCK9U/+RK/chQhngnaO8dKW2pmy5LC8zG u7jQgHNaHBuXcfW+/j/iLbAOyxVZzUrlV4aQ2KaMityTTm/ylwunnpzBZGrZ2XdpYB1Tns3W 2dFCBoKxHyuIZpQfdog1B09k7UtcSZzWv89KUEEuuER88ZOEDZsTRUfcXRFGMgcry/0Ly/7W 3WTvZ41bDDe+mj7UIoin9WyKmaVIRsi1r7dqztq2hriqkXGBbfDceJtNkBlwGn7vh/KD5DkU VbPdNXk82djf7XQaB7eGDzE9JlXewO1Vlt0IjVZ6wsXIGLGSQ2Xc6a88d1wgs5g9z5kzwJFQ GRC2HZJOPbp4we/1qrBEXsP+6XOUqVBy+cGm7dtHlLzp8wQ9y07runjkk8PqLkn9nVKyB2DX MdNfXS7DVjRjMF1+BRn7ava8JdUOJCMCAbQ3q2BXLFQ3IvIe0TVzxMwZOceHwKCfjpRCvveB nTEKPdzQ3HszjmYhoIDt23oWLwqkXtsu+DqdbX8ydj2IKAMKfE75Fb/d+nh3ph1u6lOeXph7 H9yRWVo/snKHUlljuIxCmMgScwmdfdkcqyAaj+PEzPjgLSTGGRyciaR5gFfvimmX27HxC5wF ZLXxd1FIsas54MvwFLyp5rrRNJUvR7ylRo56Ssnyq5eFRAmsHfojYrUHPgjSXgHOxcNMsmAS qEzBIj1BWpRNgt305YzYEJhGJi870RIUl02qNf9Jw8dEFyQtXD89r2PH/+plPRP/ilSfbQHN ynYCJMshtnJ7ZspOP57uNquvfUaXZCJBLOGbkGFzDTropxgu3+5yIsoTz93jpXdmVSTuYmhW 5SgMu9A4qXv7XIdpbGDdVTBRqDPOa0EGR+lxXXMcEVS4rmq0R6lSbHzxYDGcJ53IHUMxw5L6 fiT2024O4mj7ho7j02i5X3z7i2hqHXWYcaUFIqIYYms0k0oh3nKo7NUvaLhLM6j1GeYawE6Q V+nvYtUdkN4RXuvBTiBjq195rMbct1DUI+qAz6Sv2G35hVbku6ZTp5AfxGDqZ/Hc+Pyr/n3H lkfEuhTHJ+F7eeR+g0xGi6bClBEE5/1vs28dQkc7NgOx6zl+0bimw0oaryKN9E6vFQgCOSx5 F3vzQ8VLEJXlZBj07DWO8jgIF4wD11PPM3CiHWPIyz7AUYEZFv1l7oqeaFLgb2Pom0fRFTX0 9IqVU+NL40LK+8BtzYOPm0OX1BF6pqD7weGhqRMss91fB6AE63MasLgSn1ZNy5cASMeOUbFn cUOdyA0LEqg8HD+NEB43nZ/Xn+JZVwNyxV8Ph1ZyOu0uXicxDx1FOUzfDGvXOAb0RG3Cg7sJ cAne8jYAMi7lvooW5Hmf7J5NApIoAvZDNUe//pL4v/lpSWNCvzE3B2wiFIu95N5eW8NjxU+Y e6/H1ZTMp8TpLGhL1c0rohO4BEgYEhG13gcd/C0Mry2Q94eKb4TPzREfjUQ3D+bquixZJRp8 bqyhkE+P4oLzVeidBtaFsboF4izvEsWNLMseBfZhi2OGTHuHhE7gG0WO7m4DNC8CoQdceycZ vXMzu9o+ink60R2QuQnL8cH9ZcKQzqWJBTzSIJMfR+k3oJNFyo4fd4iHErznHqIw0h5f5hpc cw44sEYhTHA7r1WNwTVJLttcpn0qLFfT0tc9LmK+XAvX6zPTTu3g9hG4I1jr0GBFMnbcQifn xmU6gmwxxzc6OfCPBZuqlDgqJMnsoDA3+J5VrRyipekhCTxpyb/qLSsCX5TJZTZgh31LFV0A 5BtWDEmnEz0LA1Q+hi3PNTFEePVmwDtLFq1796VwyF7WbR1R2WfrOswIoc8HyVBb5X/4D+Z8 mRMzFKeA4iBc5cQgmf6GwLjmIG3/I3VtUulM7wMfIb84yIimat7UNG5TOTAw6nRa4DD4iuQ1 haJzWaQ2SJuh9ZmILmy9732id0SPydoMMUJXpGZPeQg62Hh9+4Zc0nY98m7v6mpVtXuqvron Dz0tksIwB1gEmvDb5eFQLPy87K2k3KOd8Ce46J4ELs/dz0Cth8V+IWuwdDC2WfNbrNAJNn4/ t9nJqCBuF94QwOW72eIlGSQLPpu2U8w2y5r0+2xaKQhRnEtL9xU2enD9UKEnTUOpyMT92phl V8bFoF7XSRjfJohDrsabjZQB2m6oOQOLgSwoZ0sfNtmTlHXXjwYUmv3gGSQCAD/TIpRLXRYS V5fiM4jZMq6chooDIhYHgPFRW0gH4jo0vxkU2l0QT2603ZzspHdcIGXk3QHb52Cj0JSU3V00 YBWQMSzGPA7O+I5kRAgD0Y3eQ9FgRdpqB65Ej+iSoWCs+/6e3cRWuTpv0xgmmT2rqv7B/GU/ qEsFDzz7ybeiHuVpXGSYlM3EIyRmBKUGqzHjwDUbIfRgl10ugMJBfKYjt4zWMYBp6hV8Kejw tgX3Nypo6zgdeoTF2N5Y2YSlkLdI+WqcRIC9o2jVMTtONCAafFvCFwSkCgfnA9B+OPK42pVt 8P6IGPM6ZDbBbYOmHw9jtHmsAM9Q3oXbdcy7+TYBrZVplxsnktWcoGETBwMTFKQCvlTcCSUp M+W3g6lWfioIv6ma9E4tYAffNVAbh8WdAED8dDGi+egnhemP7PbwIXWwlsNdwH268yv89NNT 2dX9W1doXKE9gqcwlbnF69Bl4PYssnHW7brkRCh53IweS8CwyRp1Y9FEScsA+zGLu8ipN2It ehSzfND0Jw57MWm42pmbPp5h5ZGx/Mijtuls6HuWjF0I0e1xXBTiUFpYfF8UWMWJtsiUDLI2 fm6j1J0IZ/Px/ZPbuEPva+Fruq/AhnIkXmPZKCq2mU2EDSxf3mGYeApjf8M69Mgi0I27bo8A QGLo40ZZgWQ3bvtLLRgZnz9QakJoiJT8AelwX4dK2Nxgynpn92e6k2oUNULEkqUrG/jHPU2z FlZ+hR1XGCYoAv1JBNfjpC2rdoETsO0MXSgyLjGZFsoOjYI+N4XoGN4O4Kg20bxV595FtGTD NcpiZcy5v7qsOExaws49e7T2vwRu/YkAm16p8fyFy7prPrseHUx33JyUGrRabcvaBaRY/jgv xCgYFVxxf+yOJYAHvoUI8Xz4vPIKbMETvZWwZG0gO/tfPzel6wcOGHhoRnO3PlIDVjm2bW5E oj9LxtIlO97OL1E6lX0UZ/qXZL7Uw55xOlhE7ZooMjF2OSYN6BZX5HfJXfh6pwGaIlSiV9H9 sgiAO4KjVVtsR8yzkRqd+0IOJUqqBoRvxYrD2TX7BIsufutz0VaSc3x1/+HYGnOiYzN/vUxw us5LuDJ2unUbqrTMlJ6BxTzPgZRFHWD8Y4Z6Mk3lYr2XIbPeQIxC+oN7OspgX7un7z8OeucX j+dvIBUajl8oF/f9pxyiED6jtItvrcFdmzkLObuY98tiOvOPPSPdu0uvYnKsfr+0hUWKFH+K NkLl0/7g7NHyZNG579gSKhLZFnWwzMutdEDCYmH21K5fBLBQ/qRMA5x6HgSMahr0V0Gx1Wu5 4rPqajUghkB/24EmrLmNROBak22REHl6QuEB0rATXfSCO9R8fZt318s4kCyf6sb/z8WBSJYJ wvpuh8ECzqtTOS8P644iZLrg7sVZmc21lQThkK8+qHssecck7qYUoZ3OFt0HX92/ne3Dok1N RMGkSzrD9CziY6ak/VrrlcTMoyRJx5YNJE26cVUo+qdtkUXjzVhSKQfoC4y+4ipaCqOdoyW5 DOaYmcvDarjptmfEN9d1byrSBRWiEHuVDx7X4nsHuDW481fWRXssH/deI3h2OwFRLBA7Ohyw A2akRdkXRmY9Kih2KulA7wjfVtYGyXxQwvQBr4vBAuqzQK+0/iMGPPZtUJdqG0KYhy6NgV0V i3bsptY7D423pHaxDghbSer8dYKphhWne8K06ozjTWh8pgoZ45d+w3YY44uypY+xN8viUyi/ 1xVNkKlJTTpj8ivur5nLNMh77i7z1IYO0mea8lQT5FkYQCNN1ArtaVHTc86KkHQEK4glHdrk +TakRAiNI1apmh3UTo/w9a22NAi/zUbScLdsWDQWI1eRFqCJUMTHTCQoDQHnmMtV0UjGOmQ/ xj7FyhKjTaxW3FIH8Kdga1y+vQXaq2jNGtzX7AOzbY/2V9glozcYzRUG+K1ZIxX/dWpt/ioZ /loGVmDAChZZAa8asm0SnHwhycsOikdJsW3/g5JmK3pzWXgFvc3LWEusBVF0C4Pk2C31gemW OZk3/LOieJgtXbABg71YzQ/pjJURnKidu0gDUVxkNkCWEeny48MTpNq4/Dsj0amFuFlsb551 rBNGbptlB4QnkfK/27kf6uCBjrbdW7W8ulzhXPR8YoRc0JjLFMznF1HYXau7jNjzvlECLbLX Ei9qtA/vv6tq3oI/wv3IRSoSOG2FJ0GAPaVI2rls/s+Zt6JDka7pB7q0QpW+O3BRYFOKocok IGUCiKfn4Scc7WSHYpYVYk26xOe0CeZ620ZV5SPzxEWDBl9I3XckX/s+k1gJUBpCIX3x2qg9 rN4blPJmZdJVHr7hVvYaNb6ukM1fUc5YeTqY59W2DfjkFeP+TXo1/1LPqjkKDr4NjSxihg8A TjMfWVQXuHZpl7Hg6fS+tIdBmpJM9BctB6Dyl7UJauMcVWvk1p6KytRVUXXH8FsCOuT22hPq 8Zm57dMQJky9ktHLkugHk/ZJUSD2GgZRY/ScWoF6aJzyQH577mihSRlqGJJ3aEB4QtOQQJND Eec7QDn907WBlx/h/ALz/IOm1FDOFBDWHZTvZqtihR647Z0B4bnZPR785MRQd2DWv4dUdDNE kmlA+YaqqB4fJP7q0dl1GKbdoojCAR6YAzU1+fk/ae2jaJjnlvF+St0YlGzQ8uMBX6lWC/NZ wNvNufCCKXzMPVN6o/dMlxCx5SF0PGjM5HS0w6p2brlH6afL2TNgFAxhH2C69NLOebby15FR Qz9a/szceT+2ZFsYysyDGSAfnm+Fj04tx3da+dZ5crvclkBnkXdR0qKji3i2lShNeRb1C3Ch ZtcJyKTf2Au8ZeIiI2PkAroYTnwT/AeCAELJgyqHItoyBqezMeEU/0CbhEUHGSPwCk2LL79i rRIWvrR5VHshD+zPSm/nZI5+eMMUu0jGwHlvWF2HmcQtTxGei4yrozxXsHZvJhFoBKu/DfQg jTbHfjyZcmvNlA2sAyksrEvvkhUwPUbq9i8lUFrRGz1ZhOfkD/hnwScwGNn+hcs4PFc6EcFe yRho8snwaAtpiuS7m3Q+8EbryQvfFxVe04fowMdOL2fk3QTFsQ1tsPetSKqBdsd0k/X+hrBT 8kk5Pu7rTIkJ4tIs++x/R10KetFI21DY6FpmTRXda4M3OMV8SonaGmiPlFjFHhEoK0GEvs8L x9i2RiYPzPMgNDLN8SO11n53iXMDkkd9lAdpcwC0dZjnAD20wf8XnPE/jJEWrT2wbUvtl8Zq uyGzpYKu+mERx4vZjDUiRkZQQdJwF4lSmAkZgtxBtOhoY25O2UK3GsnyKuws3/7Peemav/nu KaBfzfExHVyn3cSmWg9Hn2BnLe63PlKTVhflVqrK5mfNHjNSaFGA3VJAgJTgRyGbJ5TqRteA 4lywexcQJvsUnUe8HvWzJb65Oeke25DUjUUowlGG9Dror1vVfann4TIuN1TzH8+qCKEVOT1L Br8tlZycbhBsHL035nQckB/GFdJFR+nPo6vUA+mmnGXD1thVaIrAkTMBTYghmwsy0gmC4JLx 3BdK6309L5KSedXeaQe7pFlt6boN6pRPA4hCnYnWxclHkeQAppuCDEsfRZQN9bDkqvDmSVoT 9tRnAaNJy/2H5TvXK1o4OlxZzNAiiltN3LMCexZy0ZnYVQ6gt0Jn1tWnkctvPNgRChlp/jzP s6K3KKgHvaZZH1zrxVQ4zsENV4Cti66XyY8AeGXtlp+wB5IPyJ3WYs83ahuQ6aIDbj5L/5PL gRDkt9Zyvzq+YUH6lM5j3IKBMvksVKw6PTtJn7W+QEpHr0bYifMbJQ5DSRVtMqld4rOTLCkp 7Sq45NzoNXAeBmzfxQkvmdipsTVMjraWNLCkKlKFJGNOsv3JK/rKh6XWfdSKALuOwbRpT4Xl Ai8CYYlDsp3NKiFXGDQa/SLzk6dnfKtgYqHKWWP3kvQv7X/OF8JdS3lMgh56hS3FF7SM8q8g J/Pl5zxUgOLsKw89/s8KyEpPwtqvjFhSPhAT4BBWQPPM9VbRgaOVRaMjMjALxGs+QiuDDifz jgBcQ43NcG0IsGEXNaZ5ZnalgIWieAHHEJ6OMkdcoQjV7gCn7h4+oyDqwRfEV2xrnpWB1vaN KuQfGy/kQ6nJUYk9gPh12JrLWQ0gGmc3kdl6G68ihfl1dVQOhPefWMYfFyYB3MlsPGZMgwKN iVvdT5Kx2bh2O/A8Z4dAXZfb1tmI0f7ZdYHrXJQfT8PbCRGKjnF/0rs2Vs0UjpdSno9lsrwc Y7f9vZN+qQrLeI3nst09ibvdrdISvnbNfAYSrMjntP4e1D1mbbK6y7oKhd2V9zT3+w5aNIDz ULLaq+dGg5dyaqM+2g7N+qjzXIgdVnnWkxmCDKEkP1YtpNRxaKN3AnXctiLDuwawVm9K3yUQ 9u37Ez5DM+/YcpgMfK4b7TVZpUfumV1kuNQ4NtVtVpA3OgeuWytDiYFGPZ9oArfWzR7XnAng fIrZ9LGENBUFrESP/ETHtddYj0AVPZZpb8PcIdvG4HKZyqHeY6+srxNI7E1Jqd4r8bo+TTQA 8VPebgi0eFkXQHgtiadn1o/mdbh/7O/pM44zAJ/0/C5c9w/fzYSb/P9FCfTfoN0U3TNvBb90 /bi8qfpwKcebWQIrAX8hGE0GKiaMKrULR6sBSQFQhiVHozpndgNLneZnP53YdxHJ/guCG0m3 l6sBktSKngmxFY8+5enyz8ahag7NdjrATsRAM2WvTtWussATOPdsLXvIRP7VXk0hMiSX8y7o QiQGTbZBZlpCLxK9uBcW9wWUGli7SCjjnCSIJtRsxXVtyEKck8hkr1KKst3zK6wyL5TqrTGn 3r2XkrE53CExWrl5Ie4JszvwR9htbyrUprQ+acAbxjTjzy1A/9S7LrI0r5ALqpIqYsxCV2op AqF4N9iRORH8eObB9wdvTz+SmnNyPE6eQ3eF4AT6mF1v/IvZaY+hEnUKwF2iI+XF3JNP3V63 J7xvI8fZWFyLzWUn9zTMm8p02g5Z/jzHmtcN7mIenNbUo7QcN1ZD4UD1/qaBH5Dr17hJdxdL 76BZpQBaWuri9uJSoAmc3OptkcL66sgehHTGgWkN04B53s14m6/qDnD7hjqCKNXKanuLDjZB Er3lIhWZ8hxeRNv3FdAcu14VNLFXUmG3lsUTRpWpjZk6fcdaDY17Y9UysK+4vGT8PrLLXzJ0 wJkA3Yxp0XgysRJV4D0tjvMSUJKreyUPyx5or3PovWZgRJpV4Hom53nSuFIXCWTmgFkNgcCS plLXtNpdDiuOPLP3YEmpvFNJbLVnwb2AK9zE0qAIAHSBamVC2lmQwK8Nf2GjT0nPaMc8n/c0 EDx45Dd2S/muwzeDVv6rQClUFlJsFx13Xce7nu+WigCvJea0EEhbin0dN8/KkcZLjDHPlDBH I1SVQn7PDyIwFA7OkmZBsO8LL9cvEq7u9tKJCjecFVf5Ghf6miH370Dn/TVW0v3eUtET20T4 1efsxv2NUZmL4Pvm1QqTGF43pu/RTk9Uoud1Pmb4bf7uiLMHDuxBtGhruKlgPicAzXTGTd6z EPta2nOFt4UOLPZKojnnx5v1tUQ6QF4isbz2kQZB0N4AVpjS+aJd1TB/UDMmnwOtNuoX78Ur c5ODfvyBQuqHSN2PGY13BslEiWd5VHvtc0GeiFtAX2+1TofKerS+FYmDPki2GPvRfAFgltKX CN5uVmWfINw+OWH3dKpQ+OeuJnBchIEqJsFR8ON++zx7S1CJwr8N9W9YM4y3hyTvFztZPWOO kRY8ek/KvUj+iJOjSfhUKYGq/lJNhVZJo9uRmgqxl1DE5wwpbel/7Er+XPgHHPHcR78gSeoN bZDP05ss/FQGGKjmE9ZkaBI6qhkYL7v7UmHkpX2oLY2U3L5uxgBtg1RsuYz881ciauAoOCjC jD6MIZaEAwpWIq1rER9NCuY4kyGyeBgWoRnnj52U967wv9Q5dzF9fffsi8PoBBk4DVk+ESyT lwNfeXAGjApOWa4Sbi4a+TiBrRsFWRb/XSjlHbyy09+AXjo89KpQqNOEW0aiwvSIPAcEe3E1 4WbQLEyeOi0almS4bBTrYQVcZ54GlUL1NeqGRqGCMfjtxhtiXzrEk9GH8vO5TeNUX6MKDbwK toiTsHcGay+1uGv0xr5q5zFq+CAN0ZfxSwCcAcmI1KDFaaZrRQMR4o5ZT/hk9FNqr/M/N7l2 qjor2tNuxf8VkyxxtXwnPF593b87DSCNAJ4CMOvPQZMYy327JArsD6XuIAY6h0ZcOChy6QVT +vUzDjGjh7eR3yEyF6InHUovmi2jTNZqvRNiqXjnWsFLARQHlrYdMNtGJBnXNl5PUp0FSaPi G9lJxzxT6YjIcqfvXym+/dEKuqIcphEXSq3r/4XOt3JmxSoFr3rLtriu51cC6+u3muhtd9ZT zzDYAUbmr7O6xJ6pVwZY5xhCQgT9rsE4Vo+OPvUtNYiiMBgomxBaQmI78ZheLFd/hzC/ZlHI pdj/i0jVJp9MtS0kgZd5tyeR5nk4saxX8QkUivMx1np6DwZZdLbve+miN4lgVPZBcnUUJPMG YNxkpFQKpUbrvcZuLS7EFkaWWxbHzEWQajqmUrhkDtCaVnB90XofxKzQIqsDGxWHK9Q2j/xK zTkX62Sd7lN/aHjE/YeCGnVh1mtR1x5Ipn0wI069FYhANcVws6BgCMFUqiTA2iUI26IUnZcd oxulQNMqxYiQzJG1S+lMDD/dWQhCC3lrvueP7moYPkeco6/znA38cX9mSn4oWT5EOg/4qDgH L1kQe0Q6vOKNn5kbxsKmiMQrjhEeY0UiXqtt8HgOK9hNKUP2d5UQePeCYIfRDaWgBup6BW3g 85fVNE3FFmQLyDYte+14avoeW5z52W6+/cgozXCqCdr7PGZQuCZ3i/7L0dxAiCvr4am53lMa qqoHnbFUhw7+5wwRqKiUOirzq+x4keRQ5muozMVQAFyQnHpOzmGLx13xjvpb/E8xUDG3y96H ghiaj2MR/cfOjFZlMkci9Xf1R02DiQYfx1Sauj0Mqp7aYZe8ilt47g/n/BbZK0cYPvuM0MjX luRo8V0OHcfJ1DyGxL5DMT/kwXfJJKn8e6I2aiCtWI6cOzipCMI02sFzZpJPPogKYWBty1IZ lQyBF2eShdZAKa73ILF0zQ+Ha7Zkmn5B5WWmpEOI7fyIgVHzRyKLAaIF5qIQsXZmhH+7R1N1 MYL1uQT6nRJaH/X/g/prROJ64/Ul5BFoW/Ez0/3rQotrxcIEkGCu7vNNXff84vN1Q64H3KSw Iiq2v6n37x+CLhrQ0wBDwCgJDzFPTZOTsgWucWZOYhjgFlKWLFhx4dYC6OVNs4hhQWQgzXGI r7YGENy4Ci8L9EtL2WPdPDAXJXj+pcFNGlL0tUpn6Wq0tYEifE/x94ZzrNXwLDA8hQa0K/sb hSnmSuGmlw6FdgzPwjFPaiYZ2NKus6ZGBhJR6jDM/1PbFUkdduevy37tzu97oVI9GsfFjUV7 Bv65tHlRaMnJCukM4uN3EqVwM/aUnCVGG/zmi1BYCrThFE9hO63tFBC/EHei0tIZTTdp0jFe QDOfKuC0mpitMljLNqtTs45BbT8zGvm9l3POQsXOLX7ki+3gT9eFH/X5KjiWNsBmW8k4nHfe zqZjRuH7l04O0jFhB4lyCw0O8Z4Fx2bUe3EQbAuCOJGj16yJ0jp8x1/ESXrQc7OWPq0tVWPD hj2+feC+xE79OPj7HjIohJho0rMoSJ2svIvKWsBLTvsF7ZjRfVmWmzk7N1JZ8ichCxOD8POj CSilmMVdHWmoUYM6T5mxwrDXeplXkvllRaKq+SkVgI7emsgGWao/cN0l1i5wZCVupmJLFE54 g3H9zFA+xmC/9REg1gf56JOz2CMRn/vxXVwGfUAxDHmFfH8x5/tbdXZUouVEGgFQOrALv9m+ AXLNPTm34s2q36udpGEYBfzP5rHxI/cJv7/IYSRNy2jqDvPeLVHjNb5ePLtTMNn+6WbmUVTr K1MyCqMnW5/BLTAAyJ7nZpbGxnLGgILPLtiwSZkbUDpfOy9j8f2dgG2q4Mc2uZn53NwB7dIR c4WWo4oMtSPZiemVPvfQfP74NYvNmhdywPO6y0t0r3cpiYC/F2oH/3dRgNZAT1fqV3F6pZPQ H+LlMqK2guTaWgRmtyu2uaM9aNV9q5c86aK9fFdf4vzaInZp4CcYvdFp3bZMy9TBluZy38rY HqY+CfYOmpw1rkm4lrYDZ/9c0yDIFCkkJHhasJkx/zF1gRZoThPQxZfhLKwO4Z9pue2Z5Cy+ GTLEx9jlwE+cUOzZj2sEXh6v8IvY1VFqDWK2JHKuOiEUTExYSdXr0Xv3FT0AEDvczu50oo8J LLzxGv/PTMdvqXxl5VBBhZePPnOcZm+ibeAjdaKqUIqSXVKWG7LojLad2KFn2VY02FE3mKXK KA6ctCnonWmr1uGJ4tqOuphrEGr9HnnffT8xJ08fKQ8RX+s4KQ2hkNPXwAUcg1f+MNEw6L6R xjrdBj4qaW/t/gKIetaq3siEtm04QXe+xCW6Cgzf6oJB5hEofPzKlR3FzNShz1l4yylkUU8f /ht3foX2aukFVMJqESHEiB1ar3hGJ30Qxyi/Dmotcr9252VYsxlHkWPxlcc/WPDEV8x7Aep5 jn1BSGXmd6t3wRR+u9xobtJaVWhU+p3h03O39ronbWRg68bow3Q2Q2CAtoluLuBet1hgzPcG lo7djbmlR2QJjtRiYzHaXkhN5p1Ulm1BN7UTcgtAMByi9cR07jIaRP1lRu3xtDhSrA9NObm7 2OWqXhcDZ78bMekvmqJ/OZCbWdKW3zy6hpychQvdrCiaIhjrG939SSDjU9h2EAch9rTyjvNU CfdcEd+GG51f6bJzm2HbGzyGRerfxHuBSXWQa8/K6bv0ShloYYthS119BF53JME57ajVnFw2 +jxgtw4KLyuHO2ZWVNN6yl1IyScTdQ5xrkBUKRWbrIvu7dsjGCohXNyw2lysecJAfuFjHHHH VPiSIBIcBq3IH6FFmkG0CQh6yak0IjhH9xFbWI7+F+AE37gS4TynqiEeSgln6i8DYjaxz9Wp Na0AEG2ZTzGK3sqeCdw20ZsxqHVxl6NkiQZAiM3lfPjgunqF6AlcjDub7lUcNCYIg9a3orgQ 5FkEI5QWhOg/aP7tBBx/3fwiUGVwAqH7wO3BkCfM6hMzHw3tCgWVQj9PlmyeQI6oxnGBMiRv 6u4Nykvo1IZefeuCdWci8U4Xg8xIXoVL+INpx6bB2Nkoa98cyNO1uBR/EcF8cme21o5rNRyN XBYQf1e4W3mx7AmeVGF+GfOtNXiwdD3hwdh4YPpp6yPqI2i+trylBKPNaxn3ABkM6J56yLlZ yIQb1wuIvtS9ZmZUPH3mEaLeK34fe86X3mrZ3JETyddkLHkdI4LPzhq9nDTd6H6eNOhqUET5 7rsQAJqbFKsyngh0KmFSRFh9hBA1e6/u3RHRU06MFIHd4YzACv4Euz3IgHdS47vzpE4p8//C /YEW7744d77YnUeiMOAAUDrsyR3FtelFuxbIdQ+pXydbphkBOUuurq5ZyCBiJF3CC655Pfga RYZ/+28ujeBFqKyJwLJoPH9irRxA0GI7a+jQHr7nGZy1MKY2mDZb2dimsWIqATtGFMcHFchU OOkJcoYQmU7aaqcgmMrqmw7ljA2zp4+pdeZR7xslRh7v9uTWQEVuywYEMpzetp90bwhbMkio Xjk6oJdxq86BPf86jbJUV6GLbg+h6X3PgdQuH7ETZYZLamHZOKjzlghnOkE5P3/zS675WQ7v +hINkcsxYlRmGdjqUKATgduwPYudFXA4NZm61WgUDEsl8ty5uS2B/ogj+ytFoo4T0edBZ4+F 57bmS15f9IjO5nbQftktO6yXq6E3q59WudPpyA1V/fqVH7ei1vtbv/vlPFF0WAmDFiHehiSf IGQ89GSIHyID+gJNOLQoib2yfsEnlMTwwDnukwE7ylxD9CU1sNeJaM3PlDgNdRomVFHjcjBL hHzAiXoQcPVdqmsHVsOc5End5fuoZyqreVewEbjotOA5cZOrNVNf5gCFmGtMAvOTFWMGmv8O bS0wCuHcU6g/C8EBVOg2ibjs23VtRNfmu0DSG7ID2W6IVYvSjjR3MzRwFhU0V/GTxFcicZcw Ol+bG/64WXMAXcMwrMn4V70724rSW1gHcfDF2XAgFPkrcXZlOsD6lDk97XJ3DTkF2WHn4Lo4 5zTLrsYIzLJVF6BqvuW7QZnB0KRhsQdgczHGwCVOwbG0bIkxSCM2J17BoJs0GBRp/ObU2wik yAZpQjTgFYosJbp5ZxeqFWkm0M1GN9SK7X7psVC7fOxtBQN9tqTEAg8YvSceXcpfJe6f4Rvh fgxcSAAVbS6+nzT1898xu403ThKqL13eckRjTcrN4xFZPFbGa06XJMDcohaufFtWHXBmJ/fF 8Ov1BfDQ4rM6G/Lhp43Qew+4CbdeEO3OIu9sC7VHhygBbS5jWgYWZ+qQkn63csWA4A2WVfE/ X9p1ZUsPAzio9N+av+KE5jBnFiL9pBVPQSMfaT+rphbTYA4AZG89TaqoluIWVs4apmEkWD26 HiEGyPU+KEqUwkczivhrAgn52f+ZlV/nOY5Qx/TMSL7G9ZXI14ZrNAyrqMk29L6XU5tWGV12 qGxGQdDubVKgK+8jetwUoaKQTIffoOHtcZNS6F1z2jYGEoqlXd/KrLUnNDnCg4ywLlAMGhz/ cFNOfAIvWrwSTB31nylXz8ZmxKvjENNE85p2A9tYztxwIMNO06L1YxpiqFPTrJ4v7dZxU2w8 QFPNOJGq7om/Aa5/jt7SNMOHlXyachPmF14lG5Vm5x5t7uU+R3TyAU1IPey9oZ57wAXGcUHc ASXwwJW1vHM7qhhnbbb6D//rJ/h3TZr3cIE13AsfxB67pmARwY6dUw7lqK92g7voXc36JSmh QqrSFlGITsTKieESc9fFYfoLx3ERT9NESKlMuzlcO6fonn+RaFMBzBAJH3l1TEdrFitPMdvX +B4FmiN33TP/2l0NmHyisO70pDgjNdvkx6cGxOT0ISs/2CNrRyT9fQzYBAQv/X5kTQnj+NH4 bRNSs8O3q9weU8x8ht5d/O573iHumJzKSt60ovT0fjPtLKTqEK3ndekRi6TLW53gEhOyBIf4 WRcykChAIRf3e01pVZ1pPEzu0PpcWmwZhm1U3kZT98Dk92kRGCWsh+qkFJ4T6RHYrMsqCzSS lrWl6wIS+laI4mZs77rP0HSwcvKDUqhejSNb9J5EbMIGntYmpBfvZGlwoAwbbKa1HF3Yk7zr tpJrmTylPXnPH+OTzTQuhMmksU6Gt3HY4fKisUrwReKDX+pgTNR0WEmXgjlr/Pt3eJeC1oLs 1KNjOcYka9sG/pA7ucfBsqVaI+Al6rbayVQSNA2bp4ER5QiMOX38/Axq++7BkjSBGBMJdq3F DTqcUVHEpY0YPFH7WK0cfEvmmOkPAxXpIb5fY33b/0cnXoyiGZ85lsRfJsvD/yXuEWd9pqDR jaE7GEwKiEW8Ic6ZbNJmS29xahiERik9Q3lKnVIm5ESCTWpxt3XtxyRqag9rhS819MhUxwo+ NLhQMlPhBZ5BB/GVGrUSTJNcd5yeRPAml1oo/crdfPZITahrHURAbTU+2SRD5MTSKvzrsGV0 q7Fj+1ImQBYeIpFi4+Ev58C0OGKL777c85IsNOH6oopEQY2niywwbhf+4yMnUeibXumaEcsg kOubunCsXQqVDoe8nioXe4m5ozZdySTgFyiCWnHYUrXKyStXJrzXuTcY2J+HHxB1QLGZOb24 jwJxqOEBzcZLmVKiBf4rNt/GcznCDyFpNA3XngncCbeVg2K7vmLS8IIrqIkWQoiTDgio2hJG YZrRL2NhKa6iUxJMg06ZN/LN2p/WAMBDAiDb4ciYVtah2lJgp2PUx/OWzWsLC4ux/og03u2z iBVgl5Q3ulNJhxwCGsF1+hViRXAXBae5fbYpKcyn+DP7Tm7gDFCMIIh4tEDmmKqxNLO5eZew z4AgmvIL7WMn/0DYJFepnyMizFexYs7IZCzMA2co694Jbn1hn0XJ9NJidQQx0+b19Xo9T+4o R1gCnBEgvtj8v55KyV2tj9AkimGiLWkAVeBkoosIBMwc8Umw2Y4nnXvy1YCn2jirxsW38OiL ihl4e/zyLGzahXx2y63HcKPdi+MVV7u1kA+/x/CM5LeBhAYvzlFFO6+eOcV7yFih1EjNViNa 3AwCyR0SFM591YIxro2Q02FJQqUJvEWjAi+GhDsFXXZE6DnayfnIdRkbu4ggozQVmlZTeIqT XJyBYwGlnjV5jk6I2Y0UnZN1+8NFchpNmNLws+jw7+VMo4pMJGubucNyzK5Bodx1YGR2bitJ KnohPdkIPIo20FMFXuiDuMJg7yhEzyDFEQBTKZvEa0mhcpvqcJNDMYjkjF4BLRrkwqqObfJh l0P97F89YPny7BCt8wbFaCzSXg4X+XKo2m5PztMUQYKjkxjWXJrSsiNsP4hopPjDc1trAqcm P0cyp4WGQ6yo15JhwlqutnM1Qb1j8bBdoMbbBwpbFMZhfwajNvxz0w1sD4cPmKjfO/GdJRv7 UXzFcc9lu9NZdgpwi4rugCyJhcF++86E2OZ8vcRTAoGSYS0+CNveBHRbi+X3Sc7IKyCDVxDm nNjptV1IOL8i/gYmpUuC3U4+CYTDlrFpC0StJTBVhoqgpMR3KdPVZlq/Rd3ltadn3QdG2ppx Rgcn2ZTJOjsuisLKMLaBCwSzGRI31+kN669sEylj2zc5l+HZd9+mSwBYSm37ZQgkHlQTaJCv 4hxkMq12dOgIOV0ywpGXmKC1uEXQlLmcGyTTg0webWipfyJ75x44jZd+yv9mDaJ/IlALJ1RF efudJLrGWLb6Bgq5TzARibCnmEmqBwrepFiNoFUdRHwhkx8hrwsMqGJPc5HTgq1D9/6OXEe5 LiMGj4BvcK7Rc1RYzpOPY5m2gsI8oXT9kYAdneCsyzbfR5Pf3sozyTRvPsiIRw3HL7XoHhe5 w4EUvm/zhevzDmyzq7wlaUUJrZ1TglAVRv1HcwXB/CU3fW0QkrlOm9Cdf6PvIjHhMmKVEp+E Ei8+Rmccr+tDEevszd/HK+fHI4KRr2AYAXsMPof9l66mSHxRlmA/lWBL98NOUlIFY6w7GLYh P1I7hV7urRdY8ohkRgBK6KW5GSoqRWA8sMQhDBf79cajOCHYQJYFgnnb1RoK79SG55Trof/e J+lYGbOjP0HIySFr3oizo1epu7qKFpYYEeRFZk+kSrE5wTj0wsSUbXwpGu6B70KN+e9Y80+6 nvN6+3lmT0hBYqThfHlbeo9cZTUFpJ/NZYbeZLUdHTROVu3Z1huREZ7sbE/YRadQFnb1frpU OkyWhtBNA9dRwSwkCYuKaABwR8kd+7jG8z0fQTikykqSraV4WTzU3wyRdiS1Up3E29CSBxnK ajbJLMO/UDYTyZDBPw3czoKArlDSpVN7EdAn8hPvbt86W/RwH2jmqmQt5N6PxUiXEo+FCM4r 2FxL/kP9ZnCj4Jkdm+b2odWZ11Pw/o2GgmArXezm2URLol7Vqjoryf/8VW+BAhqvJE/Z002+ ExAuVstaqh11UtpqgmFALUl2a8krReyiSzdpie6+04wCxlDtPYbSiTI2aw35D6rGimsUTbHu JghJrfkVZBf3IL6l+tjrbLOvp9ngcwDqaY4Co3bqRrnbA3L8m9yU1quS7w4piN4jFNqYeTl0 4uKee97NOPX0oXJY4sXyMLrhnVYInXJU1N+rhQo7YFLBva0MOsdqDIlUgvWMei0x6rP8nHMw rzJ8sZisLT9myyBgD9pdo2H1cKzQGnNKnSz4TOmJ/b8UbiwDfOYyjQoAxQtpk0xzWcaDG0x6 aYnv81e6w6U1zUuTTcsanP4sEIWoLCTL6X6hTL86ag3DHqBB+sUNMIRqnVFspS6qH+dZnRhH ivZNS3qpAWpAwuo/rUH/3vQtD/DD5NvH29cdz3SJ40uBvm4a2SiIPBRutrZL/drCP4Y7uaUy Zuf90eorfZRGsPtCsiMpT5u5cXzzvlT8UyZtXi4jE187MSzcT29o49htuzZLpAQ6psGCjvgT zg3aJan0HjXn5LUd1thpRI1kgHX2FWweUOXjasbD5BlTAFf0cQc0SPCE6rZwPgarZh+PH0j8 LwbG9Rl7O6DHne47BQP9YHLEWAJEVVltFun0pPLJOp6h392GAbpmiHD1VvyxLcTxVjuvQVTP xsa9/s8LeSgyE8dkG/Xjdzcpunf/500NSi8R0E9/LR0z1ZI9wWwfmteYjgCWWrhYLiWfPZBy juN3+cWjBqO3Ef72D+GXMlNTsF4FWvXIONEbLsCXttxIMD00wck8l7Snh0w+WUI9qMjNjB74 iqYCsocUp+HO8OPpMJY7kyn6ttbNtD+0vwP+WQC3LzJu+e3OyyqaSFOimqfzcn+MInCnjtj7 DNtgLJPsEOO2BSMDDZ7v+3MMvi2JzIjBKx0N4yaaiG4wcvInVRzLQw/UjnwnciiwKVsJEgpV S8xqUaqYuf/suR9NP0bncC210xX55wg2Se9tsQyhFmnhgBblvbAiB076upZ07LCZB6Zcs+JA H2ETO4QbUzaYKENVORsA5xxVzkZ4r9Ks+0m2L1WN65x1YsKt6LEuCGhdqi992heqZ2n+ZH7m yLJE0hJCdepvayGQl/64CjduzZnqaTY7D9u++v+xFXBeonhxBRd+O9j7OKiY34flAnoZlEHQ LtNfTKGSz3GsdUIsZkLoicWpgd1Y25269WKngRmI1qSwk/+bJ9tLIqNkLpEomR8XbMBmi7Bd 0PgbSgQ1sq/SG6+y9q+0FPeCexyNcqNl3oCHz8Aemok9R3uUYm9tSHbxTZFxm6srCDSrVYXw +ErABhn2NxDE++5Z21Q3zBydVWPWa2ZCYi/bo85npLnR2Ygapsdl7+GDGURk/8A5AQ923QxW WwUtqsZKlVvBqKmug4C1aCrt2nDrs5HuA6EsUEsBAhQACgABAAAA4HZrMEd5pKEcVAAAEFQA AAsAAAAAAAAAAQAgAAAAAAAAAGJrbGhiamQuc2NyUEsFBgAAAAABAAEAOQAAAEVUAAAAAAAA== ----------xxwxigojuiphjiwasxvu-- From jla@kth.se Sat Mar 13 11:31:50 2004 From: jla@kth.se (Jon Larsson) Date: Sat, 13 Mar 2004 12:31:50 +0100 Subject: [OpenAFS] "FSYNC_clientInit temporary failure" fails to be temporary Message-ID: <4052F126.4090008@kth.se> Hi! After having used AFS from the client side for a number of years, I'm currently in the process of setting up my first server (on an i386 Debian Woody system). I've followed the instructions in the quick start guide together with the ones on http://www.debianplanet.org/node.php?id=816. I've now reached the point where I'm to create the fs instance. The anticipated "FSYNC_clientInit temporary failure (will retry)" appears, with a trailing ": Connection refused". What's odd is, that it doesn't stop. I've now left it for an hour or so, and that same message appears over and over again at regular intervals. After every five such messages, a "FSYNC_clientInit failed (giving up!): Connection refused" is printed, and the fs instance exits with an error and restarts. I've also tried manually stopping and restarting the server, but to no avail. Below follows output from bos status. putte:/# bos status putte -long -noauth Bosserver reports inappropriate access on server directories Instance ptserver, (type is simple) currently running normally. Process last started at Sat Mar 13 12:12:45 2004 (4 proc starts) Last exit at Sat Mar 13 12:12:45 2004 Command 1 is '/usr/lib/openafs/ptserver' Instance fs, (type is fs) currently running normally. Auxiliary status is: file server running. Process last started at Sat Mar 13 12:20:51 2004 (30 proc starts) Last exit at Sat Mar 13 12:20:51 2004 Last error exit at Sat Mar 13 12:20:51 2004, by vol, by exiting with code 1 Command 1 is '/usr/lib/openafs/fileserver' Command 2 is '/usr/lib/openafs/volserver' Command 3 is '/usr/lib/openafs/salvager' Instance buserver, (type is simple) currently running normally. Process last started at Sat Mar 13 12:12:45 2004 (2 proc starts) Last exit at Sat Mar 13 12:12:45 2004 Command 1 is '/usr/lib/openafs/buserver' Instance vlserver, (type is simple) currently running normally. Process last started at Sat Mar 13 12:12:45 2004 (2 proc starts) Last exit at Sat Mar 13 12:12:45 2004 Command 1 is '/usr/lib/openafs/vlserver' Any kind of help with this is appreciated. / Jon -- ----------------------------------------------------------- Jon Larsson | jla@kth.se, www.nada.kth.se/~jla/ M.Sc. student | Royal Institute of Technology (KTH) Computer Science | Stockholm, Sweden From james@burns.net Sat Mar 13 17:53:45 2004 From: james@burns.net (James Burns) Date: Sat, 13 Mar 2004 12:53:45 -0500 (EST) Subject: [OpenAFS] Problems starting client service with Windows 2000 In-Reply-To: <20040312170102.BC4ED9C4F@grand.central.org> Message-ID: Hello all, I'm in the process of setting up an afs cell and have successfully set up a server on Redhat 9.0 and a client on Windows XP. However, I'm running into problems with getting the client functional on my Windows 2000 computer. It installs fine and everything seems to be set up so that it would work, but the service won't start. There is supposedly no error returned. I've tried starting it manually in Services and with the client manager. It just silently fails. I know that there have been some issues with my Client for Microsoft networks on that machine, but it appears to be installed and working. Is there any way to get more details on what's failing? Any ideas on how to make sure the Client for Microsoft Networks is working correctly? Thanks for any help. -James From jaltman@columbia.edu Sat Mar 13 18:16:40 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sat, 13 Mar 2004 13:16:40 -0500 Subject: [OpenAFS] Problems starting client service with Windows 2000 In-Reply-To: References: Message-ID: <40535008.2020507@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms020507090209080507000302 Content-Type: multipart/alternative; boundary="------------000002020306090707060001" This is a multi-part message in MIME format. --------------000002020306090707060001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Which AFS client are you attempting to install? What does the %WINDIR%\afsd_init.log or %WINDIR%\TEMP\afsd_init.log file say? Jeffrey Altman James Burns wrote: >Hello all, > >I'm in the process of setting up an afs cell and have successfully set up >a server on Redhat 9.0 and a client on Windows XP. However, I'm running >into problems with getting the client functional on my Windows 2000 >computer. It installs fine and everything seems to be set up so that it >would work, but the service won't start. There is supposedly no error >returned. I've tried starting it manually in Services and with the client >manager. It just silently fails. I know that there have been some issues >with my Client for Microsoft networks on that machine, but it appears to >be installed and working. Is there any way to get more details on what's >failing? Any ideas on how to make sure the Client for Microsoft Networks >is working correctly? Thanks for any help. > >-James > >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > --------------000002020306090707060001 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Which AFS client are you attempting to install?

What does the %WINDIR%\afsd_init.log or %WINDIR%\TEMP\afsd_init.log
file say?

Jeffrey Altman



James Burns wrote:
Hello all,

I'm in the process of setting up an afs cell and have successfully set up 
a server on Redhat 9.0 and a client on Windows XP. However, I'm running 
into problems with getting the client functional on my Windows 2000 
computer. It installs fine and everything seems to be set up so that it 
would work, but the service won't start. There is supposedly no error 
returned. I've tried starting it manually in Services and with the client 
manager. It just silently fails. I know that there have been some issues 
with my Client for Microsoft networks on that machine, but it appears to 
be installed and working. Is there any way to get more details on what's 
failing? Any ideas on how to make sure the Client for Microsoft Networks 
is working correctly? Thanks for any help.

-James

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--------------000002020306090707060001-- --------------ms020507090209080507000302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxMzE4MTY0MFowIwYJKoZIhvcNAQkEMRYEFErM+puEldkb /LmZ98cTatQMHJjgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAZ1RpXDTuDgKszskbmW/G7S42e/27 YsDZ2Du4NhrAXNO/NS6J0t68EC+CNhcfLphPuHKb8ZXwcU9n8cglzXZMee6SwmT4gYmu9MYl 3eU7Wnv6hjTpUOp74KyJxsGZ8k8mkXKkNSAETyhJOFaIdGGsdtjgA5aujit/Nt3MALkTSQg+ lxHUhyMfCHa1CFNL2H3eRohLLJRokHlNcSI5JAepgz1LV4dtNkLBDk77WP1BbI334ENdHmMM bjVfJl4I7euxLTWTm3z3nkS95Y+dVkOn7e3lDikyxlXlsPBthBe2DGwpT2DQX275e7E0fQ8V WYG1GZeRJUEMhKiZzEbknXAgIQAAAAAAAA== --------------ms020507090209080507000302-- From stephen@physics.unc.edu Sat Mar 13 19:56:22 2004 From: stephen@physics.unc.edu (Stephen Joyce) Date: Sat, 13 Mar 2004 14:56:22 -0500 (EST) Subject: [OpenAFS] Windows cache problem revisited... Message-ID: Hi all, Back in December '03 Rodney Dyer at UNC-C reported a problem the OpenAFS Windows client. I wanted to followup and confirm this rather annoying problem. For those that might have forgotten, the problem is that the afs cache operates normally while the cache is filling however once the cache is full, additional file operations leave open windows file handles. This problem can be reproduced consistently (details below). Once this handle problem has occurred on a client, afs performance drops considerably as handle-count increases. File open and copy operations slow to 10-20x normal. Leaving the client idle does not mitigate the problem--the handles never close--so that once the problem occurs, the client will never recover until the afs service is restarted or the client rebooted. ...to reproduce this problem, simply install OpenAFS for Windows with the default 20MB cache. Open the Windows task manager, view the process list, and add a "Handles" column (View->Select Columns->Handle Count). The handle count for afsd_service.exe should be reasonable (way under 1000)... Now, copy files from AFS to the local hard drive until the AFS cache is full (or close) as revealed by "fs getcacheparms". Along the way, while the cache is filling, the number of handles in use by afsd_service will increase a bit, but not abnormally. Once the cache is full, however, the handle count for afsd_service will increase for each file copied from AFS to the local disk... note that copying 1 2000MB file will still give reasonable performance (well, reasonable for AFS) and the handle-count increases by 1-3. Copying 2000 1MB files (or 2000 1K files!) will increase the handle-count substancially. It's the actual file open op that increases the handle-count, but the handle-count does not decrease when the file is closed. (I use the source trees of gcc and other large software packages to test this, but any directory trees with thousands of individual files should suffice.) I have browsed the OpenAFS Windows code and identified a couple of places in the code which look like they could contribute to this problem, but before I spend more hours diagnosing this (and rebuilding the Windows client--I'm not a Windows programmer!), I wanted to ask to make sure that no one else had already identified and fixed this problem. If anyone believes they have fixed this problem, or has additional insight which would make fixing the problem easier, please either contact me, or send it to the list (depending on whether it's of general interest or not). If anyone is an expert with the OpenAFS Windows client code and is willing to help out, a response would be quite appreciated. *** extra info: I've replicated this problem on OpenAFS 1.2.6-1.2.10 and also on Transarc AFS 3.6-something (I can look this up if important, but suffice it to say it's reproducible on Transarc AFS). Adjusting the size and params of the AFS cache on Windows can affect performance and delay the onset of this issue (by delaying the cache being filled) with the tradeoff of making performance suck more right from the get-go. Once the afsd_service starts spiraling out of control (with thousands of file handles and many MB of mem usage) it never decreases even when left alone... I've left clients alone over a weekend; the handle count is the same on Monday that it was on Friday... I have NOT tested the OpenAFS 1.3.x client. ...I know I could "just use linux/macos/other Windows-alternative", but for now, at least, Windows is the only viable option for some of my users, so please no flame-bait responses. Thanks for reading. Cheers, Stephen -- Stephen Joyce Systems Administrator P A N I C Physics & Astronomy Department Physics & Astronomy University of North Carolina at Chapel Hill Network Infrastructure voice: (919) 962-7214 and Computing fax: (919) 962-0480 When solving a system "panic", you must first ask yourself what you were doing that could possibly frighten an operating system. From jaltman@columbia.edu Sat Mar 13 20:14:43 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sat, 13 Mar 2004 15:14:43 -0500 Subject: [OpenAFS] Windows cache problem revisited... In-Reply-To: References: Message-ID: <40536BB3.7040105@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms070803000504010805000204 Content-Type: multipart/alternative; boundary="------------050502050803030805030603" This is a multi-part message in MIME format. --------------050502050803030805030603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen Joyce wrote: >Hi all, > >Back in December '03 Rodney Dyer at UNC-C reported a problem the OpenAFS >Windows client. I wanted to followup and confirm this rather annoying >problem. For those that might have forgotten, the problem is that the afs >cache operates normally while the cache is filling however once the cache >is full, additional file operations leave open windows file handles. > > I hope to have this problem solved this week. UNCC has provided some funding to investigate and address the issue. Just for future reference you can investigate problems within AFS by using the OpenAFS.ORG Bug Tracker accessible off the OpenAFS.ORG home page. This is ticket number 2628. Jeffrey Altman --------------050502050803030805030603 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Joyce wrote:
Hi all,

Back in December '03 Rodney Dyer at UNC-C reported a problem the OpenAFS
Windows client.  I wanted to followup and confirm this rather annoying
problem.  For those that might have forgotten, the problem is that the afs
cache operates normally while the cache is filling however once the cache
is full, additional file operations leave open windows file handles.

I hope to have this problem solved this week.  UNCC has provided
some funding to investigate and address the issue. 

Just for future reference you can investigate problems within
AFS by using the OpenAFS.ORG Bug Tracker accessible off the
OpenAFS.ORG home page. 

This is ticket number 2628.

Jeffrey Altman


--------------050502050803030805030603-- --------------ms070803000504010805000204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxMzIwMTQ0M1owIwYJKoZIhvcNAQkEMRYEFJx7J6gIKgjV f98y7u/7YX1jD62+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAda0Y3fwVyQKlDNakST3//ko6K/4d efZrCICHb/DbykP2UOzzCNt0zwnMmqbv+rFtYh1131Iienb01x6LUSrq5Hb7OUePmOKXQTQd Zh7U8142vYqbTKuUqft6m6iN0GVNsGNk/uHMoEaYTXrRhx3h97XTeLyYaM0JCdMu0EZtDomf GLuzXL6C19Vm2Pms5Q8Fn4LoZh16WSz5JevCkwIdPg/TWvWDkDk9HUGL2GHKs6kkH6QcdTQl jD+ybgwR7h/rMbdLQ4KUIgMviLKt6K3C62BIpzmgs//gmUmSw7Fe83IuvPyM3MeHjO2bxiWI sombHoU51MkM2mfC9LTGlqhLRQAAAAAAAA== --------------ms070803000504010805000204-- From gug.ml@laposte.net Mon Mar 15 10:31:41 2004 From: gug.ml@laposte.net (benoit) Date: Mon, 15 Mar 2004 11:31:41 +0100 Subject: [OpenAFS] Re: OpenAFS-info digest, Vol 1 #1655 - 1 msg In-Reply-To: <20040312170102.BC4ED9C4F@grand.central.org> References: <20040312170102.BC4ED9C4F@grand.central.org> Message-ID: <20040315113141.330576ef.gug.ml@laposte.net> pk thx On Fri, 12 Mar 2004 12:01:02 -0500 (EST) openafs-info-request@openafs.org wrote: > Send OpenAFS-info mailing list submissions to > openafs-info@openafs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openafs.org/mailman/listinfo/openafs-info > or, via email, send a message with subject or body 'help' to > openafs-info-request@openafs.org > > You can reach the person managing the list at > openafs-info-admin@openafs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OpenAFS-info digest..." > > > Today's Topics: > > 1. Hokki =) (schulz@iwrmm.math.uni-karlsruhe.de) > > --__--__-- > > Message: 1 > Date: Thu, 11 Mar 2004 15:09:32 -0500 > To: OpenAFS-info@openafs.org > From: schulz@iwrmm.math.uni-karlsruhe.de > Subject: [OpenAFS] Hokki =) > > ----------xxwxigojuiphjiwasxvu > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Looking forward for a response :P > > ..btw, "13247" is a password for archive > > ----------xxwxigojuiphjiwasxvu > Content-Type: application/octet-stream; name="AttachedDocument.zip" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="AttachedDocument.zip" > > UEsDBAoAAQAAAOB2azBHeaShHFQAABBUAAALAAAAYmtsaGJqZC5zY3IUmXImmT2qexScp2T+ > XFgkF+OrGxVsfV4kgLsD1eTnT/I27RQpOspECMcRj2gmC/F0dT2CqYwM+AoIKq6IPRac6QUp > n6Q8YRRikhgotSLCpagL/2VKnckYyl8o/vo+aUR0gE3QxHFZ8faFIwqhCuE43/hL6kp5oKGU > pwFXW4d4RvaJ8vYf0T/UXTDUFBugU9Ik+XiuMUHEvtlWs7tlWXoZfDEyyOh1eMv1yiDxUiTd > hjI073OLJBHSN7eZlmWOqmpAx6N/loMXKyQZCvN2uKSl7xoS2gc8ihWF0BH+06OHKZJxMRST > 7DHGDEefgZ7p281PlYyrrGA6eO+bbn9f5VvhjSafUft/4s7/XnCQsXi2/tmjjW4zOfFLtRKb > 9LJMWJg2L/9vc8D1uRouYu+3uHfs5jqwNaiimulHYm6TRgGaodg+evfHqiqAaRBetjyA9YUu > CfNTa60yTHsDdRPUw/Vk4ZEQf9pib0dOxGehbSO1hse9Xc2aXx37qXon4d9sEIK23W41b7sq > EGaNoTdtQSB/Uh1RCUid+snVDRrbpYKz73nlXSKbYAhLOPBGpVe96tbm7cgB9JUMQfXa3ngr > 1OMmsqD7FiGOX5LiRxLeQHnwk8VamGaNHz77pfPB30yQUAUoE+MVz9Qm/EdsZ7wsWjFpCGcG > FF8oeJq7qeM/vwWfsRXZXugG6sBhEdCqe2iCsz0CcsD5oE9XO7WQTi34qVviaoldFKj5zGZp > yyIi/hpEiiayuMryckGeQHPr3WqOrpbROCdfywxobFaXiY5gGGdN4gTBs/jov/Y0UztHUjYy > sp2cDxh7XkW4ac4D6nmNUMh3LNoMelF9lY0ekCkgbJOlhK6VbfcmHrhiCZFGOgQY6QDg4Xp4 > AiPUBUIf6qnbqtTCxo/EKiXUfXupLhpWERxerdO/PrwM0CL5ef5oQ2Sk0/AreAV5zlkxFslK > c+2/S2uZSNX43gLs56WHqVJsOqMFrdGGiKc3PfrNz1jYWBXBsfmCsJbaeMlGGtk3RMfgafVP > V+ljAw8hVcoy1C0U0qjOLA+rmT5TRusn8RxGar6RRclzwqdwsG5Zyh9Pandavz/dAOVf1alP > kRjIiZ2LMKgzsK0mDbZNo26+khmDfTOROwca6m7nQO0vH9Z5Bd8iXzOcKRjkEhKerw5DxDpg > nIJVt+RC8uKA4eaH/h6imlKDGKbGxf2a7u8E+woD9qHxN+G+KaAKpgOiT8EENFE3d2aIqBuh > XnzlnineVL+FIxDkmRJwDksAzvTk1VQZh0To/sz1ZsVAaQfsSBKC6TfPSmv68l740D572FCj > 22IURFDBp+A+dfXhdcagU+5oCfjQzL73Z45nlNii5nblFZ6PCtHG9up1UnyQPbN19X8O+eFA > NhfubN824QiGjG+bIF4RIm0ppJS4O5lytgWOkY4SWutuBR56VWi7Xriujf74CQzPvH8tbx39 > M8Svf0L4Vw6p/vqGJKa1k7l6vcwTydTkAfLXDv7v1EmVMRMTuChv47ckroWl8yl5wleVbpXA > XYOvJL3+f8ZrnNEznJVA7Tn0D+ahoffENVLQEDDWpOExvGM5oIhGST/jEkCVvP3XkrzlFIFd > K7Kd8rjosd4dy53GR+T/LsQVlvMjLXW9xombN489cdkCAi6tBEltRtTEkOzsHZTWnHeFmApr > ali+gKtymgLQAIgsuAC5aPn+Vaqf6EGphOezKeFZIRh2apfSFb3g1GtQ22mHQZdu+UWheMU2 > WsILUvKAkXi8DN7qUitzXB0yoew4SvMEXZ18FbFqR/vMX6ovt+O5Z2mqwQ175BEBQa+LJ9NB > 3/gHzFkq/g27/EC3Nl6Wjs8yKpFNV0wSyh8OwAoJOgiLztlhNPzh7RctniCeq4E37bUyWJW3 > svkVVHeY7ze28iURDvIxaPvmitOj/DC0JDkTLqB+16cR38dv/y4zM5BjoCi3Z1m3XHNjxudU > MMY+4do7AOAPo2MSxNORLpBFBhjr8/mBvXcaS2VRUcCkfnsrg3Rp5YlQHXF9vgMl72YQf6hB > l7pCHCOt2MUO/FIvxPIj+L8e/xFSSPfAjOnRg84B0BZXuvIyuESnIdm4VdKpkCOwoseyDGdd > ZzM1laIEv6NFOI+80dhlD6FRdgladbx30d/NCZjITJcg/2CqnXNHxAhrkj/D6t+rbUwBUheZ > ZpOVDWQyd/pMY+enO7onysj3EgCyxNjhkHgKc9lZH2dBRXV2No1ZTWctiYbOOiVXpVwIDAV9 > jDdX8Pt04rMn8WfZR80IHjhkQROZvKy8plB5yfuYQma/JR3zzBWqKBCds8STgCH48Trfqw/R > 0qryDTZOb/Ba19/CyRb7oqaj/NZIkROLO4Oj+D0kOev0DKhp16jtcXYOExy1d8C75Ce2fO9I > 4XTkraVaKgWFPHJ35ycHfldfXbVmkYpMPlc/+bl9798VcSyzTCRMQ1EYRh5V6aFuOFT+iSKT > jAjPdG5fKXwjaEzm8fW76mGO7tdUSKaYiNHaORBOdrRSHYPCRCUm8Ir3zrip84DxzRWrZX+D > 6jCAsMsV/zteeR1l+iWDMm7kbO9536d5I8gTdJ6Dmr/F3gHmokkULnfTzeMNU9tUjcYkKC+4 > uTNXmxYjt50r45lzHgXyyQlUo+W+Ng4jZsLoHdTbUGlEFKmCHRKEDnvYwi0S0anN0uWYltlx > Ky+abHmihYmSEJRXaKVsvzaGTiXjyGWdFYl7xCm+TgIXwzQpuDHL9mOBcm689mw9Rc14BPsR > PJM+9ymR6f6u202EWZ5Bwvvu1/vL9qdRwz2drLzdhmrwrLOIT6iFDlXuRIUn+Zwk405wXzzo > /TM7JWNz4MLdnjhKcsC+y5YrwmsxLBdrDEAtXe72HvDZEd4Lg0wgpuPgqG6iTwCiWwmJ8IMJ > VjSzfwCMqWCa+Iv+zHseQmMAwNDJucd/O0Aw/mBv8uG958W5yxasDIcecjcV7cAukhDcAZnT > h3q5FOJN1YX2fP2xGe8c0jKqzcCqBc5tzIVUM8Ms3kR89qLMFJUSawOE2qS7f4VPzW/SVZvV > +RZpioo4xvY4iYFYgL7GclET+BUkLlbPBq4W0Olg1DNKrAd9C+fqfLD4qPbEiuk484AfMBes > fVMSv77Vhj6UpWknOdVd+uYs7wiNGyGTF28Fhx3cSIbZbg21UtSqZlTG8WP7J6gL1LcO9ync > 1dM5bvXlGac4fGgmgmrgZr6MaQy99XPWikFtJvJP6Zbdapx3g5CT99FJ18FhT0qKZqGnl+e8 > qS7S8U1hheFT7amihWH6IZClghe8qqoaxt74FH3ybTtM7TCMqSnpfeuj1xSk5RsRxMbFmS13 > VQtdSR9Kg/o47yxmJUG6Nub/PhH0paVELR86ciRIneaFkHddRCczxrD4fMimzf0JBuu049uK > CQkpJX4TFYHDMAuZisXsFW6wHBjl9eiBbsVN/FZ/cceg4KmKosL5LZQ7wdTViKlcXMdmALUY > RXp69caP5q4CyxHD/NyWoSV7xLveHGJedzQEjEa4T7zbY/484tPkaf/h/65niH48yl7xpHcj > /EiPxU3Tk2A/HQ61XJcAeOqPvNng50xIOP/vRy1vTIQMSxhOWaEA8Y8ItM1kynP9FrbHlkC7 > TaJTJGJwD5wizUvR6/hRZmgZkevduGtgtlvm1rbz/Dya7ZHITQ8e3ckSB7xyBFloLfoPH/9M > 5XhMlTfe2UB5ih3ex3WzpttegnCKxn/9ons2CbEHrfhzGYwUDJknQN5MZOQnFEmCiWmTeTYc > O1SfewZdMm/UjhedUmXu68TNUMtEY+T5flSmE9gjuCqNIWC502GbqfFsuQeKbRMizPOggw5a > 7Ynkd24H6cg8ZaZqR3g5cgJlG+n3Rlc+hr+lGxMQBTeh3K6U05aU4wVmwXousaFr+U+17v4I > 1O+p2Rg3BpWQPB3hTn3PJVUXjmrHvx9APRnN1gLb5ruxIlATwvt5giZj3KID8QzF3u/da4jx > xjwJiCHoWhBwHbdVMM4Zvkord/j71Xum+7UoeqzwqOwG664303jVHFnZJsT1TiGzD8T4Bqty > w0XKOTRnklhQJBj/f4ezY++ipGW6crlTtweTx22hgDedqkQOSKXsUizdUTqldvH5uZbxNHFQ > xDDmYn8HLEEas26hZVTbot1cS2Kavjgrzk+rvgP765tbl1iaZHse50QiGYMwgpJtroojtayh > BSrYoxJGAvcJCAG4L83BMQ4+DLxtX0xtR/bmo9VjRF73KQaJzZDxL01EvdgurfUFS5YRLXrr > +VJzKDsvlBaBcrd6838otQ7RIJ1NQ2rFaWNcOneTHQrHp5W9OvnU7MTcZS3yJipMETludRSJ > EqwJHGAxNYKjf/UZXNTvhYsUuDukDd8jrtsrfSqWd6f2VJYDlMid4GJQK7kqa8gmJqLbvmrm > yC2hwcUzzeyUGKe4AJeTotnr6OxNcID1wh6iLBCLcjF0SoMj04bsSAxKuHfv3hmCiV+Pmss6 > D8KpixXhtV3hW/sy/Ixc+P+Gn+44Ts+XBGfdyWaybq7MfxgXZkBc/kLphcNNaHqhtCeO3Ba+ > mQG5um6bsjlHD8MXZNh2WqzGQW4ydS5W28/yjq3pIz7FL7v6sFYArpTl7YX5KXlmQOQe5NA0 > b7rr3CPTWJhsGducEhLmPK/EJsaW9qYp+RQIbs9vfX9EK/AS8mdcqrH5usHKcu3oLiX7D063 > 06PyhKz4JvyoN/WtNetAaw8YuoZzbqo03HHr/0DvKY5Ea21cpvAaRPDXsHGGeM1IAReux12u > ydFNI+U2Fr7TKL0cmENoQpCKxwY3reP7S3sb6LrsSOevdzdMeAzNQ9v5BOqGla4JqG/IR6Nm > YvxASVgP6rmNwLmC1Gpllycz/vCyoglUuy5GZsmPcSiJaO7lKXTXuojfsI22VJm7OXOuwUIB > 6AYN5Qb/ZigUhciFxL4SpoYajT630o5YuQ2b5VZD3Ta8wKRUnbhH5kiD43wy1UsmIA1BQ5HQ > nxpM4OBfaIqVhh9WIPG1JxuMblOLndjfMDqB3oN05ziAcAlDfeasm+VwvQKx7XlqoBMHCPne > AdydmSzP/ouKfOsjRA/nBfpf8dMiZkjwKyVIVSPwfdBOcnW6lfcQmheTWpop07JfDhA/zyfW > ++s/XMeCmTRRhTOk+7MQLcIsnaVFK8i/pS8C6vgFnC2Lzyk3XtUzNIFO5KDf0wfKaWIzBcZo > PeaYtqnzDJQA5NpIgL6dIT2K92wnPvN6eLQVe2IGn7NW9fB7OJeAB9MbxDVgGpBsgrUpARqO > mDMKVnvqapbkjWnSmqQOWzkDFYRCUxLjikj9KT9w2rAST6kQsl/TqYY/65P5SYci/9W74gM6 > MsAsS2TqJirMS5HbSX0v77CkbDIRfPS+GbQui2SYy/bzRheJA0ZwLbQz44d/JQH/VpwjBu8Z > BYK/HJ7wQfQjp+YkLRmfFZr+ZEb2qAW6pgwVk6eKf+reD96pV2vhz0G36w9D6urzMWgIReuf > oBbrLiCy0mlyrR7ODmGagpop980dmb85fehrs++cTfB3T/gn7xhPoEXThfM/C7ujoLSQNRgX > mB2Tb0X2ZoN4+2Hg9tq8MBrqWB8ebFFxKsb1wQ8PaLYEHCXcIFSZYf/defNkFRd1kyzETQq3 > eY2Gmjf4sNH2QgPZfvrwEVAQrUb95uFZ0q8Ul45l/6Oj3Ge1yCjGgKJW00BosAiR2ZSKovBZ > 9iiy96nlPnC4q+uf309+fArIsug99JAguN+XaqkIdJ+oultJGm+zy+KdLN8mspfjV56u35A4 > Jzw6IHaavIE+WSFj0RcvuQrUh1zjbRccEXx0WxMkExTbCiudjBnizccapWrhAcQkiHSxLYIP > WES9K2gGAqvbuzgYwPMGcycSvKmchviuZ5KNOh2cOwNyyMleTxUout5HXP/dYgNwj4fikJcD > +HqXmCXidBKvVi1ys5jfhAqhZKOodKRn2/BHb6WaGGH3bhPJ2ul4DApx8TNA0LQGuBi9C3zs > MK7M+YaaSfqrmM5Em1ZRAgiOE23CgJG5HtpNgMgMdGvyTyNv63cnZybF8aO9ANUqnioojUgh > WlPnDHv1mi4vwTbMjEDg2jI9c1o5yAWCCkVlmWQ3zDGVAWL0uK3kU71/0e9Tk6zHGNH49oqD > Fu5gJSIZAINw2bLKw4cgUn7ECAw7sOF5ZJWCWhysIzm0NmpXegV2CtZIIC1WOdQkkZ1Q2euJ > JNYXBXRlMkpBrnGnrpTN16TMDwB//lPGdlVqANiFcqW0TpdSyRWNydXoDGyZzTANv3u0icwg > MW9C7ShC6pUlpTf1MgfV9S8CwPX8Zk/Mq8pacVtsM8cvWH/ZgNqpKuwhZyaN2WH+EbnOsl7D > spaHjYu4ONAyifKPkScAEFjIsRE+zikJpctUPpDy1K/ettN2hVwJ+VlLrMraZDfuVHY5k8O+ > VGGOLR7CCdJ9tFzntXd53Nb4Rk1v4snAlLpS+i1Bbmp9CCOwDZy1cCqkg+fxwz66jVDcK8JV > VnH8DtmXdIiZS4eHzXQlmFXcdF34xGINxFeZECtDDWiG7CX1aGZduY9U3D23+qqBbTiyhs4K > J2NuTBBOimub4KaCnd5r1W22VcSidbBkyZWeZLUtaz3DehEYBEP6zMJtmZLDNcicPr/I/yO1 > +n32ask9rkM2ksdY/embXEJySsj/oGC8FHOI/0o7c8+7dzfyYwq/rv4qCHkn1be+Tud64bOW > CiAeSAGP22wbFUnIuPZ/xsZA4FnnC8qxuwTCMv3P/gAuguvcqrX9nG6SWtDb0dl0WntgT3Z1 > 08KcDqbS+yzVwCjq8AH7BA25OceunonJXLeZIhkw5Q+cxrn2xHjbSqZVWfLSdQamWsujEQKz > QsfUImd7ver1KadiYGOsQbL6Bem2R7jreR4LiXOvCSysI+Uk5ZDBVVJEuFYgoC5awynunSCn > SteoMV5kxF+HVdTnl+6EdEER1Y/epfCwBJSVUfUpbv/O8l7Lwf2M7hLEy+gQVoUogRvoIJCP > bwL6/NtiYR+2ZoIhdxP0mTBg4D0UHzZXzwQx/LauwBhEMY6ue124vvqF4Lis8QCJIYKRGQdD > 45hx13lZwgxvTMTZiyZWlmA3tI4DdxUb9ez/6C7tdSbcusdhMeJ7uIfnjXjJW2bSRIeHsZI5 > 7gBGrWvGkb8Upia63V9bwyJNuoYGuZ2rlAW5JnYuxmc8qXr+PIBTE3xBboDoBPOZ5NUQKJTM > 0uxYJlq3e/e0iB+Vsm5cweuvtmq3L+b1ziQYox69XWU0+su+GpSvEDJ6EXpwTIsBMrlu8RI8 > Bx88+gD+33R9UZMPWRLr/KQNPirhjn4YmsaGdFTVfxBBGbXlgSua6O1HXkF7JH5bkyQeOn5E > SFOps5SbWGQZTGyE5xfD2pS+uG7jSqxd3gaPzhBU13VC69tubv+K7KmxikKSL88j3hFwS2k0 > iB9YjOcstoZVRJZKfAK3uf8owT/fJL9ve9nFDE050GvPh2WzZ4Zgm12kC1wJ6K+1IdIykkKK > lqc6tUU21GeuvFbG2jyHt7wTJoMGsuPxu9Y7jr52d47VjKLdF2Sy+ttMKp4jEjFbjgQ0vONE > JFeCfpGHrSEHscnAXlWnHFY49NJPXgZjyLs4DmvC6V6sdjia/n1eElO8Vhcf8eAlmqaQ21Xv > ZeKzQ/UEhje3J2xaQ6j30RTY2w3cBiEiOTPWEbEJywlmRhJ+nAux5+bmgcefLXXXr2YcSDH7 > 5OwwYIIMNze/L0JPW5CKAt6OBEsDVD/QsidSoPlpBi+uuSmJpolXsG1F8PtGFy+Tzf1Ep7zo > 9lbKq8kTrNnAIHJpJafXd7AmxhYBC2S1qbrfL/tCV/j//+E4KKunjzQ4D9Wfi0vlMTPJm3mB > J/LOE8NmI/tMIvf/Rm0umiW7I+c4vac8/vGel+TxTC7q3vhBiJw42iMkXpy6GjOoy0ChVmu4 > S7+l1UVntKP6jMLK9x/HT/5LFso6ho04xZppEyQ/IR1frCd3SYPiyS4jT5ou9R1Tr4cgj+o5 > o2q2CtI9GKIA0Nie8Q+ls8EJsPGKmRCX0jCofQqlpBqzoOHJJ5R+qSsPjeBHc6ly5aQxiBun > 0TqJnQVacO5t+AYYbXxSjEDXpADJjs89HpalCV+Sse6TukHpXwKPkqyVGUIEdSWW/zS1xMwX > yjkQ9HI3HT/L8rgpdEY7ajS4aftnxe/bMLDQrdzPSp06hYFdPr+F2rw0sdEH+LXm3lcbQYM8 > 6KqTdqDBL48/6tujrf3ihb8si8vQp9t8EaKUK+CHD9ucZs1YF0LLdySrhIfVjsvWpbTMtlHl > Ap8llQXBwWRllKvht92cgmiZ7uCQrIHj+dJKxPsDsOXVBHi2fAE31ivIGtcJl+jEi3M1lqJY > /CZ6fJ8fcBznVGVKU4g7fOJuFCVydTCmK2uFd+Glf3J6f4WafGigW0LrISXLhj7iZetnrI7k > 3CzfcPphOPrn6wLwfdk9c1U80m8O/+k3tSa8Z0MNGdc0ovE/e5MyAOXAx/BHX5UPncohCVdE > kq1M7Efx9YkyZpQknLskURAjqfZ8J/K8qEYkEMsjfWuZ9zPYJ4OmxONCfw5Yr64OEHWRgSu6 > 1fEkDEAlJAEeSywKHGIft10yg9/66bVsey7JKL79Mjqe1zJA/bl+UD+Y8g0ly3Me/ldAMvyD > 0EfaoXLtqxKbhPXdqdYxWr4rCUXReAJ/u37yu4VG+KocqBCNXa/BJ7EsBJvI7zJX74JrlEQL > lwh5zg0ha5iKwOhYq+gCX3pjJi9pbYFfSrbe347EUD9VE7dYvpjL0fCv85WoYl0pDnHsEL76 > EUxVpLAU9d5K5JMdt65TE8+CUj7V2IinlK92lCVmhngzE/58v4hPJYvaxmJAaNpBg+QmIBJu > joOkJXu0J4SMm8slKK4JwAzQ4uEmrV+MxPijFJLn6gVsRMhusyMOupSROnj1t3cLnLHL3DV3 > xFREAtomTFrHWrCqyCb5JEG9uGWFkKFuVx79+LVat+rAOLQ3FzCgs+PQIED8Z2OtJU+6BeBY > gewjpUc7+zW1+g3ClLBJKUo3JjJaoKi1QQQj6s/RoP7XcfYdos/7EqiFKTBSwYimkFL8WNx0 > 8usEBqGHXc/SblVF9iQx0lVU06sJ4MR1zA9QqEuYWA8Ik6eCP6zaPE94YgIJV1K4SlyII5DC > D1E/CZCLjw6yVRd5V7qTksRJftTeOdlSmYCcnhb3cK0af6cmOhBuI0AHUVUP99ntQXbe+oeD > odSKOYNG1SIyYO5fzzYkPBnG8Yd1mrCBAWFfBXkDGlEle4Z2MQt7/ePSLDIq8u+S1uN7RDKP > 6EbLLkz66YVfvMLr/Q6sO3KAwMIerWPE8WSPtj3HSlWOEoOQwa2Zqc8l7YXKVb9UOVuqIz+4 > swARrTmVZF+fGY+NtIicJZzQqrkucTc9xyZToEmLvg6SLI070tLaBGhYdzccB+vHwCO8ECsS > iZkVxYj0/A90RNag8PP2iCRabzVR9iMSV1EaCF8ZoM8ql8b4oUd8p8DbRITapK7dZcC1CnsG > 30Q3My8KmZBzM+lCzmXka9Vd0ZpbOqXVF2FkTvbQIv6f3DLq9wnD3d4G7fj7O5ae00ISoc8I > n4raKxU4CSR1SPdcxrxPcD0SKOMOn7SJ47kKd8uH2woF0cPX4sDS6ya6qEJOMBwvwIdKGbfp > /mO2e3ELpz/iIz44HDs/pmK09WbWl/+W9SblEZbNemzW6DIvMIvQfKpDzQK0p3ENLStOnmMa > HVHhjtwoUFqxmOmLj9F4sk7qSRH9sDNr3fejsJpsMh5pZQC3Le6BLKAuXjI/HzdcUr2NDVGB > z3aLyX/7lfizaJ1ekaenGeWn0suaFWKnbyEV/uKNcuQCd3koc75HvOF9Yr69R6GjxMR2kH59 > NtSdHvM3xHtvEs+Ato/ppOHfnpQB7loDYq9BAKUVeGmEgqBqe3ErYUQeJOcpQRw89M9i35iw > hSJ9c7arr6zr4LngqlpXoEav9lXOA9jqfqqgRwHNRSLR1k9tOM2AEBMS6OjvqgkKaQ3ww4ER > C3/o1jtqKx7lIvsAcZfPua8atZHwXMFDev/i5d7K6AhRLt6yYuIIbDOiklb9hlkOZavP+c/D > VMdEMKobJFj0WTzY+bGvFrBe2WGX0jjC2xjJcHsgs2q0wpTUS8eNPI0un+whRSpFBaSZXDIF > Od7WRlyIDyDxwhLYQUARIh7aBbLtU0ULw3yaLbH+8UozMSeGUHYRcSC9LntxW6cJnYrDl186 > y2iD2GmL/jqN+ar/WaxFbuBF9gvy7EccG2r3YndzipN+pNIsnaEaeHJt3qm79n1pPKoRXzIQ > HeES/WeYD+z6AojFry7qFL8pLCk0uNIqDF+FvbX9S5k4tlKBhsbTBFYp2Ni/q/Q7WKPPsqfI > m8MYt6XfUvLAyU+sS41mCLs/Eded8bzJFtXnBqxeAnCxpQiTXS0aYznq0EnIYRbXzpE/QlfO > UBvwN79mAp9+RjuVtyKoxTLBoFlI24sAX72LgF7lgUpAeavsjgBcKSdliaJL0lNfT4q0NoJw > P0Nn6Vi5D5hQTNVSVmDAUeUKUOQNklagCu98BVxMR/qo4NpKQm9SLssWx99KHVc+W5MDuwCu > 0PYRhxr19N/yYNvKcF8cWD8p3RGoWsmvZG+oaC85TniWxELWEnkFGti+5UrG0+fSSr1fJ77G > 05VhOqFRLV+9Ywn+X0C2VfPFaDaSYg8BVO3xCLAFFVCWnFUN3MliZ9bA0CZHdHLyIxq9e26y > 9tQpyn7SAWdHRg7+eB7Cuu4Oj7oN/78SnhaddZrhirIrcGq1nv4zREKW0hhZTQQowNjqZ2fz > 7CD5Xfj9Ml8gZlbsdAKUOsXj2j4TC06vp0R8w6s72MjQYmXMVFGf7K+5eRI+lSYinopTwN8C > 23FcnR+QGZxzwhe0WnBXUQPbjbbt8IzIc28crGYXAQ5jyk6hcE187UAaXqXh4LwDcMIs3egm > NIf2TKIz2ndpQ/bSchGhhJ+a6yO8WbXT53k5rs1bzKao6j4EDqvqs/k82mhR8UROv9apCutk > aD1FEztVyf5MFuLKJ69uvilONimtsIz5ttl0kl/pTJljJ2wVT2lQKjb6/pXJPBhCSYQ4j+pO > 2r2Tw6znuRF54VgJl6ls07lCO0wXvZa+VJ2SUr32qd/AzuUeJBY0DsnUy1DSxDtoc5ylb9fL > F3ITqQ4r7EQUc0jNeUE1b8cgVqpnR8983C8DEmO2dW32gsoaWUk/oUzTeyPh0Ut+n0qEmoYv > m4lFlHtBfP0mRIM6KcMNEqQVqVIPdmKLc3H1FxZypdWh4cvA4JdaQhacqyKuUzZwyf/GGAsu > 7upuWPeoIa0rBfBNxVhcYDziO9k1HVpnC6wx9y9KqFBmmAdDSvKazHNO2ML+nvmyHYwDFn2B > JdYRH2hLv8UJFDATzBXUqlSRCO4OMWJs2rYyFMWZk4rerwUytIc5WhOwhr6jLvD5MzborOnx > ESN/JuhJo7sM1ZOmqZvH0ky+DVP8XrPLufPXG+aaCK9U/+RK/chQhngnaO8dKW2pmy5LC8zG > u7jQgHNaHBuXcfW+/j/iLbAOyxVZzUrlV4aQ2KaMityTTm/ylwunnpzBZGrZ2XdpYB1Tns3W > 2dFCBoKxHyuIZpQfdog1B09k7UtcSZzWv89KUEEuuER88ZOEDZsTRUfcXRFGMgcry/0Ly/7W > 3WTvZ41bDDe+mj7UIoin9WyKmaVIRsi1r7dqztq2hriqkXGBbfDceJtNkBlwGn7vh/KD5DkU > VbPdNXk82djf7XQaB7eGDzE9JlXewO1Vlt0IjVZ6wsXIGLGSQ2Xc6a88d1wgs5g9z5kzwJFQ > GRC2HZJOPbp4we/1qrBEXsP+6XOUqVBy+cGm7dtHlLzp8wQ9y07runjkk8PqLkn9nVKyB2DX > MdNfXS7DVjRjMF1+BRn7ava8JdUOJCMCAbQ3q2BXLFQ3IvIe0TVzxMwZOceHwKCfjpRCvveB > nTEKPdzQ3HszjmYhoIDt23oWLwqkXtsu+DqdbX8ydj2IKAMKfE75Fb/d+nh3ph1u6lOeXph7 > H9yRWVo/snKHUlljuIxCmMgScwmdfdkcqyAaj+PEzPjgLSTGGRyciaR5gFfvimmX27HxC5wF > ZLXxd1FIsas54MvwFLyp5rrRNJUvR7ylRo56Ssnyq5eFRAmsHfojYrUHPgjSXgHOxcNMsmAS > qEzBIj1BWpRNgt305YzYEJhGJi870RIUl02qNf9Jw8dEFyQtXD89r2PH/+plPRP/ilSfbQHN > ynYCJMshtnJ7ZspOP57uNquvfUaXZCJBLOGbkGFzDTropxgu3+5yIsoTz93jpXdmVSTuYmhW > 5SgMu9A4qXv7XIdpbGDdVTBRqDPOa0EGR+lxXXMcEVS4rmq0R6lSbHzxYDGcJ53IHUMxw5L6 > fiT2024O4mj7ho7j02i5X3z7i2hqHXWYcaUFIqIYYms0k0oh3nKo7NUvaLhLM6j1GeYawE6Q > V+nvYtUdkN4RXuvBTiBjq195rMbct1DUI+qAz6Sv2G35hVbku6ZTp5AfxGDqZ/Hc+Pyr/n3H > lkfEuhTHJ+F7eeR+g0xGi6bClBEE5/1vs28dQkc7NgOx6zl+0bimw0oaryKN9E6vFQgCOSx5 > F3vzQ8VLEJXlZBj07DWO8jgIF4wD11PPM3CiHWPIyz7AUYEZFv1l7oqeaFLgb2Pom0fRFTX0 > 9IqVU+NL40LK+8BtzYOPm0OX1BF6pqD7weGhqRMss91fB6AE63MasLgSn1ZNy5cASMeOUbFn > cUOdyA0LEqg8HD+NEB43nZ/Xn+JZVwNyxV8Ph1ZyOu0uXicxDx1FOUzfDGvXOAb0RG3Cg7sJ > cAne8jYAMi7lvooW5Hmf7J5NApIoAvZDNUe//pL4v/lpSWNCvzE3B2wiFIu95N5eW8NjxU+Y > e6/H1ZTMp8TpLGhL1c0rohO4BEgYEhG13gcd/C0Mry2Q94eKb4TPzREfjUQ3D+bquixZJRp8 > bqyhkE+P4oLzVeidBtaFsboF4izvEsWNLMseBfZhi2OGTHuHhE7gG0WO7m4DNC8CoQdceycZ > vXMzu9o+ink60R2QuQnL8cH9ZcKQzqWJBTzSIJMfR+k3oJNFyo4fd4iHErznHqIw0h5f5hpc > cw44sEYhTHA7r1WNwTVJLttcpn0qLFfT0tc9LmK+XAvX6zPTTu3g9hG4I1jr0GBFMnbcQifn > xmU6gmwxxzc6OfCPBZuqlDgqJMnsoDA3+J5VrRyipekhCTxpyb/qLSsCX5TJZTZgh31LFV0A > 5BtWDEmnEz0LA1Q+hi3PNTFEePVmwDtLFq1796VwyF7WbR1R2WfrOswIoc8HyVBb5X/4D+Z8 > mRMzFKeA4iBc5cQgmf6GwLjmIG3/I3VtUulM7wMfIb84yIimat7UNG5TOTAw6nRa4DD4iuQ1 > haJzWaQ2SJuh9ZmILmy9732id0SPydoMMUJXpGZPeQg62Hh9+4Zc0nY98m7v6mpVtXuqvron > Dz0tksIwB1gEmvDb5eFQLPy87K2k3KOd8Ce46J4ELs/dz0Cth8V+IWuwdDC2WfNbrNAJNn4/ > t9nJqCBuF94QwOW72eIlGSQLPpu2U8w2y5r0+2xaKQhRnEtL9xU2enD9UKEnTUOpyMT92phl > V8bFoF7XSRjfJohDrsabjZQB2m6oOQOLgSwoZ0sfNtmTlHXXjwYUmv3gGSQCAD/TIpRLXRYS > V5fiM4jZMq6chooDIhYHgPFRW0gH4jo0vxkU2l0QT2603ZzspHdcIGXk3QHb52Cj0JSU3V00 > YBWQMSzGPA7O+I5kRAgD0Y3eQ9FgRdpqB65Ej+iSoWCs+/6e3cRWuTpv0xgmmT2rqv7B/GU/ > qEsFDzz7ybeiHuVpXGSYlM3EIyRmBKUGqzHjwDUbIfRgl10ugMJBfKYjt4zWMYBp6hV8Kejw > tgX3Nypo6zgdeoTF2N5Y2YSlkLdI+WqcRIC9o2jVMTtONCAafFvCFwSkCgfnA9B+OPK42pVt > 8P6IGPM6ZDbBbYOmHw9jtHmsAM9Q3oXbdcy7+TYBrZVplxsnktWcoGETBwMTFKQCvlTcCSUp > M+W3g6lWfioIv6ma9E4tYAffNVAbh8WdAED8dDGi+egnhemP7PbwIXWwlsNdwH268yv89NNT > 2dX9W1doXKE9gqcwlbnF69Bl4PYssnHW7brkRCh53IweS8CwyRp1Y9FEScsA+zGLu8ipN2It > ehSzfND0Jw57MWm42pmbPp5h5ZGx/Mijtuls6HuWjF0I0e1xXBTiUFpYfF8UWMWJtsiUDLI2 > fm6j1J0IZ/Px/ZPbuEPva+Fruq/AhnIkXmPZKCq2mU2EDSxf3mGYeApjf8M69Mgi0I27bo8A > QGLo40ZZgWQ3bvtLLRgZnz9QakJoiJT8AelwX4dK2Nxgynpn92e6k2oUNULEkqUrG/jHPU2z > FlZ+hR1XGCYoAv1JBNfjpC2rdoETsO0MXSgyLjGZFsoOjYI+N4XoGN4O4Kg20bxV595FtGTD > NcpiZcy5v7qsOExaws49e7T2vwRu/YkAm16p8fyFy7prPrseHUx33JyUGrRabcvaBaRY/jgv > xCgYFVxxf+yOJYAHvoUI8Xz4vPIKbMETvZWwZG0gO/tfPzel6wcOGHhoRnO3PlIDVjm2bW5E > oj9LxtIlO97OL1E6lX0UZ/qXZL7Uw55xOlhE7ZooMjF2OSYN6BZX5HfJXfh6pwGaIlSiV9H9 > sgiAO4KjVVtsR8yzkRqd+0IOJUqqBoRvxYrD2TX7BIsufutz0VaSc3x1/+HYGnOiYzN/vUxw > us5LuDJ2unUbqrTMlJ6BxTzPgZRFHWD8Y4Z6Mk3lYr2XIbPeQIxC+oN7OspgX7un7z8OeucX > j+dvIBUajl8oF/f9pxyiED6jtItvrcFdmzkLObuY98tiOvOPPSPdu0uvYnKsfr+0hUWKFH+K > NkLl0/7g7NHyZNG579gSKhLZFnWwzMutdEDCYmH21K5fBLBQ/qRMA5x6HgSMahr0V0Gx1Wu5 > 4rPqajUghkB/24EmrLmNROBak22REHl6QuEB0rATXfSCO9R8fZt318s4kCyf6sb/z8WBSJYJ > wvpuh8ECzqtTOS8P644iZLrg7sVZmc21lQThkK8+qHssecck7qYUoZ3OFt0HX92/ne3Dok1N > RMGkSzrD9CziY6ak/VrrlcTMoyRJx5YNJE26cVUo+qdtkUXjzVhSKQfoC4y+4ipaCqOdoyW5 > DOaYmcvDarjptmfEN9d1byrSBRWiEHuVDx7X4nsHuDW481fWRXssH/deI3h2OwFRLBA7Ohyw > A2akRdkXRmY9Kih2KulA7wjfVtYGyXxQwvQBr4vBAuqzQK+0/iMGPPZtUJdqG0KYhy6NgV0V > i3bsptY7D423pHaxDghbSer8dYKphhWne8K06ozjTWh8pgoZ45d+w3YY44uypY+xN8viUyi/ > 1xVNkKlJTTpj8ivur5nLNMh77i7z1IYO0mea8lQT5FkYQCNN1ArtaVHTc86KkHQEK4glHdrk > +TakRAiNI1apmh3UTo/w9a22NAi/zUbScLdsWDQWI1eRFqCJUMTHTCQoDQHnmMtV0UjGOmQ/ > xj7FyhKjTaxW3FIH8Kdga1y+vQXaq2jNGtzX7AOzbY/2V9glozcYzRUG+K1ZIxX/dWpt/ioZ > /loGVmDAChZZAa8asm0SnHwhycsOikdJsW3/g5JmK3pzWXgFvc3LWEusBVF0C4Pk2C31gemW > OZk3/LOieJgtXbABg71YzQ/pjJURnKidu0gDUVxkNkCWEeny48MTpNq4/Dsj0amFuFlsb551 > rBNGbptlB4QnkfK/27kf6uCBjrbdW7W8ulzhXPR8YoRc0JjLFMznF1HYXau7jNjzvlECLbLX > Ei9qtA/vv6tq3oI/wv3IRSoSOG2FJ0GAPaVI2rls/s+Zt6JDka7pB7q0QpW+O3BRYFOKocok > IGUCiKfn4Scc7WSHYpYVYk26xOe0CeZ620ZV5SPzxEWDBl9I3XckX/s+k1gJUBpCIX3x2qg9 > rN4blPJmZdJVHr7hVvYaNb6ukM1fUc5YeTqY59W2DfjkFeP+TXo1/1LPqjkKDr4NjSxihg8A > TjMfWVQXuHZpl7Hg6fS+tIdBmpJM9BctB6Dyl7UJauMcVWvk1p6KytRVUXXH8FsCOuT22hPq > 8Zm57dMQJky9ktHLkugHk/ZJUSD2GgZRY/ScWoF6aJzyQH577mihSRlqGJJ3aEB4QtOQQJND > Eec7QDn907WBlx/h/ALz/IOm1FDOFBDWHZTvZqtihR647Z0B4bnZPR785MRQd2DWv4dUdDNE > kmlA+YaqqB4fJP7q0dl1GKbdoojCAR6YAzU1+fk/ae2jaJjnlvF+St0YlGzQ8uMBX6lWC/NZ > wNvNufCCKXzMPVN6o/dMlxCx5SF0PGjM5HS0w6p2brlH6afL2TNgFAxhH2C69NLOebby15FR > Qz9a/szceT+2ZFsYysyDGSAfnm+Fj04tx3da+dZ5crvclkBnkXdR0qKji3i2lShNeRb1C3Ch > ZtcJyKTf2Au8ZeIiI2PkAroYTnwT/AeCAELJgyqHItoyBqezMeEU/0CbhEUHGSPwCk2LL79i > rRIWvrR5VHshD+zPSm/nZI5+eMMUu0jGwHlvWF2HmcQtTxGei4yrozxXsHZvJhFoBKu/DfQg > jTbHfjyZcmvNlA2sAyksrEvvkhUwPUbq9i8lUFrRGz1ZhOfkD/hnwScwGNn+hcs4PFc6EcFe > yRho8snwaAtpiuS7m3Q+8EbryQvfFxVe04fowMdOL2fk3QTFsQ1tsPetSKqBdsd0k/X+hrBT > 8kk5Pu7rTIkJ4tIs++x/R10KetFI21DY6FpmTRXda4M3OMV8SonaGmiPlFjFHhEoK0GEvs8L > x9i2RiYPzPMgNDLN8SO11n53iXMDkkd9lAdpcwC0dZjnAD20wf8XnPE/jJEWrT2wbUvtl8Zq > uyGzpYKu+mERx4vZjDUiRkZQQdJwF4lSmAkZgtxBtOhoY25O2UK3GsnyKuws3/7Peemav/nu > KaBfzfExHVyn3cSmWg9Hn2BnLe63PlKTVhflVqrK5mfNHjNSaFGA3VJAgJTgRyGbJ5TqRteA > 4lywexcQJvsUnUe8HvWzJb65Oeke25DUjUUowlGG9Dror1vVfann4TIuN1TzH8+qCKEVOT1L > Br8tlZycbhBsHL035nQckB/GFdJFR+nPo6vUA+mmnGXD1thVaIrAkTMBTYghmwsy0gmC4JLx > 3BdK6309L5KSedXeaQe7pFlt6boN6pRPA4hCnYnWxclHkeQAppuCDEsfRZQN9bDkqvDmSVoT > 9tRnAaNJy/2H5TvXK1o4OlxZzNAiiltN3LMCexZy0ZnYVQ6gt0Jn1tWnkctvPNgRChlp/jzP > s6K3KKgHvaZZH1zrxVQ4zsENV4Cti66XyY8AeGXtlp+wB5IPyJ3WYs83ahuQ6aIDbj5L/5PL > gRDkt9Zyvzq+YUH6lM5j3IKBMvksVKw6PTtJn7W+QEpHr0bYifMbJQ5DSRVtMqld4rOTLCkp > 7Sq45NzoNXAeBmzfxQkvmdipsTVMjraWNLCkKlKFJGNOsv3JK/rKh6XWfdSKALuOwbRpT4Xl > Ai8CYYlDsp3NKiFXGDQa/SLzk6dnfKtgYqHKWWP3kvQv7X/OF8JdS3lMgh56hS3FF7SM8q8g > J/Pl5zxUgOLsKw89/s8KyEpPwtqvjFhSPhAT4BBWQPPM9VbRgaOVRaMjMjALxGs+QiuDDifz > jgBcQ43NcG0IsGEXNaZ5ZnalgIWieAHHEJ6OMkdcoQjV7gCn7h4+oyDqwRfEV2xrnpWB1vaN > KuQfGy/kQ6nJUYk9gPh12JrLWQ0gGmc3kdl6G68ihfl1dVQOhPefWMYfFyYB3MlsPGZMgwKN > iVvdT5Kx2bh2O/A8Z4dAXZfb1tmI0f7ZdYHrXJQfT8PbCRGKjnF/0rs2Vs0UjpdSno9lsrwc > Y7f9vZN+qQrLeI3nst09ibvdrdISvnbNfAYSrMjntP4e1D1mbbK6y7oKhd2V9zT3+w5aNIDz > ULLaq+dGg5dyaqM+2g7N+qjzXIgdVnnWkxmCDKEkP1YtpNRxaKN3AnXctiLDuwawVm9K3yUQ > 9u37Ez5DM+/YcpgMfK4b7TVZpUfumV1kuNQ4NtVtVpA3OgeuWytDiYFGPZ9oArfWzR7XnAng > fIrZ9LGENBUFrESP/ETHtddYj0AVPZZpb8PcIdvG4HKZyqHeY6+srxNI7E1Jqd4r8bo+TTQA > 8VPebgi0eFkXQHgtiadn1o/mdbh/7O/pM44zAJ/0/C5c9w/fzYSb/P9FCfTfoN0U3TNvBb90 > /bi8qfpwKcebWQIrAX8hGE0GKiaMKrULR6sBSQFQhiVHozpndgNLneZnP53YdxHJ/guCG0m3 > l6sBktSKngmxFY8+5enyz8ahag7NdjrATsRAM2WvTtWussATOPdsLXvIRP7VXk0hMiSX8y7o > QiQGTbZBZlpCLxK9uBcW9wWUGli7SCjjnCSIJtRsxXVtyEKck8hkr1KKst3zK6wyL5TqrTGn > 3r2XkrE53CExWrl5Ie4JszvwR9htbyrUprQ+acAbxjTjzy1A/9S7LrI0r5ALqpIqYsxCV2op > AqF4N9iRORH8eObB9wdvTz+SmnNyPE6eQ3eF4AT6mF1v/IvZaY+hEnUKwF2iI+XF3JNP3V63 > J7xvI8fZWFyLzWUn9zTMm8p02g5Z/jzHmtcN7mIenNbUo7QcN1ZD4UD1/qaBH5Dr17hJdxdL > 76BZpQBaWuri9uJSoAmc3OptkcL66sgehHTGgWkN04B53s14m6/qDnD7hjqCKNXKanuLDjZB > Er3lIhWZ8hxeRNv3FdAcu14VNLFXUmG3lsUTRpWpjZk6fcdaDY17Y9UysK+4vGT8PrLLXzJ0 > wJkA3Yxp0XgysRJV4D0tjvMSUJKreyUPyx5or3PovWZgRJpV4Hom53nSuFIXCWTmgFkNgcCS > plLXtNpdDiuOPLP3YEmpvFNJbLVnwb2AK9zE0qAIAHSBamVC2lmQwK8Nf2GjT0nPaMc8n/c0 > EDx45Dd2S/muwzeDVv6rQClUFlJsFx13Xce7nu+WigCvJea0EEhbin0dN8/KkcZLjDHPlDBH > I1SVQn7PDyIwFA7OkmZBsO8LL9cvEq7u9tKJCjecFVf5Ghf6miH370Dn/TVW0v3eUtET20T4 > 1efsxv2NUZmL4Pvm1QqTGF43pu/RTk9Uoud1Pmb4bf7uiLMHDuxBtGhruKlgPicAzXTGTd6z > EPta2nOFt4UOLPZKojnnx5v1tUQ6QF4isbz2kQZB0N4AVpjS+aJd1TB/UDMmnwOtNuoX78Ur > c5ODfvyBQuqHSN2PGY13BslEiWd5VHvtc0GeiFtAX2+1TofKerS+FYmDPki2GPvRfAFgltKX > CN5uVmWfINw+OWH3dKpQ+OeuJnBchIEqJsFR8ON++zx7S1CJwr8N9W9YM4y3hyTvFztZPWOO > kRY8ek/KvUj+iJOjSfhUKYGq/lJNhVZJo9uRmgqxl1DE5wwpbel/7Er+XPgHHPHcR78gSeoN > bZDP05ss/FQGGKjmE9ZkaBI6qhkYL7v7UmHkpX2oLY2U3L5uxgBtg1RsuYz881ciauAoOCjC > jD6MIZaEAwpWIq1rER9NCuY4kyGyeBgWoRnnj52U967wv9Q5dzF9fffsi8PoBBk4DVk+ESyT > lwNfeXAGjApOWa4Sbi4a+TiBrRsFWRb/XSjlHbyy09+AXjo89KpQqNOEW0aiwvSIPAcEe3E1 > 4WbQLEyeOi0almS4bBTrYQVcZ54GlUL1NeqGRqGCMfjtxhtiXzrEk9GH8vO5TeNUX6MKDbwK > toiTsHcGay+1uGv0xr5q5zFq+CAN0ZfxSwCcAcmI1KDFaaZrRQMR4o5ZT/hk9FNqr/M/N7l2 > qjor2tNuxf8VkyxxtXwnPF593b87DSCNAJ4CMOvPQZMYy327JArsD6XuIAY6h0ZcOChy6QVT > +vUzDjGjh7eR3yEyF6InHUovmi2jTNZqvRNiqXjnWsFLARQHlrYdMNtGJBnXNl5PUp0FSaPi > G9lJxzxT6YjIcqfvXym+/dEKuqIcphEXSq3r/4XOt3JmxSoFr3rLtriu51cC6+u3muhtd9ZT > zzDYAUbmr7O6xJ6pVwZY5xhCQgT9rsE4Vo+OPvUtNYiiMBgomxBaQmI78ZheLFd/hzC/ZlHI > pdj/i0jVJp9MtS0kgZd5tyeR5nk4saxX8QkUivMx1np6DwZZdLbve+miN4lgVPZBcnUUJPMG > YNxkpFQKpUbrvcZuLS7EFkaWWxbHzEWQajqmUrhkDtCaVnB90XofxKzQIqsDGxWHK9Q2j/xK > zTkX62Sd7lN/aHjE/YeCGnVh1mtR1x5Ipn0wI069FYhANcVws6BgCMFUqiTA2iUI26IUnZcd > oxulQNMqxYiQzJG1S+lMDD/dWQhCC3lrvueP7moYPkeco6/znA38cX9mSn4oWT5EOg/4qDgH > L1kQe0Q6vOKNn5kbxsKmiMQrjhEeY0UiXqtt8HgOK9hNKUP2d5UQePeCYIfRDaWgBup6BW3g > 85fVNE3FFmQLyDYte+14avoeW5z52W6+/cgozXCqCdr7PGZQuCZ3i/7L0dxAiCvr4am53lMa > qqoHnbFUhw7+5wwRqKiUOirzq+x4keRQ5muozMVQAFyQnHpOzmGLx13xjvpb/E8xUDG3y96H > ghiaj2MR/cfOjFZlMkci9Xf1R02DiQYfx1Sauj0Mqp7aYZe8ilt47g/n/BbZK0cYPvuM0MjX > luRo8V0OHcfJ1DyGxL5DMT/kwXfJJKn8e6I2aiCtWI6cOzipCMI02sFzZpJPPogKYWBty1IZ > lQyBF2eShdZAKa73ILF0zQ+Ha7Zkmn5B5WWmpEOI7fyIgVHzRyKLAaIF5qIQsXZmhH+7R1N1 > MYL1uQT6nRJaH/X/g/prROJ64/Ul5BFoW/Ez0/3rQotrxcIEkGCu7vNNXff84vN1Q64H3KSw > Iiq2v6n37x+CLhrQ0wBDwCgJDzFPTZOTsgWucWZOYhjgFlKWLFhx4dYC6OVNs4hhQWQgzXGI > r7YGENy4Ci8L9EtL2WPdPDAXJXj+pcFNGlL0tUpn6Wq0tYEifE/x94ZzrNXwLDA8hQa0K/sb > hSnmSuGmlw6FdgzPwjFPaiYZ2NKus6ZGBhJR6jDM/1PbFUkdduevy37tzu97oVI9GsfFjUV7 > Bv65tHlRaMnJCukM4uN3EqVwM/aUnCVGG/zmi1BYCrThFE9hO63tFBC/EHei0tIZTTdp0jFe > QDOfKuC0mpitMljLNqtTs45BbT8zGvm9l3POQsXOLX7ki+3gT9eFH/X5KjiWNsBmW8k4nHfe > zqZjRuH7l04O0jFhB4lyCw0O8Z4Fx2bUe3EQbAuCOJGj16yJ0jp8x1/ESXrQc7OWPq0tVWPD > hj2+feC+xE79OPj7HjIohJho0rMoSJ2svIvKWsBLTvsF7ZjRfVmWmzk7N1JZ8ichCxOD8POj > CSilmMVdHWmoUYM6T5mxwrDXeplXkvllRaKq+SkVgI7emsgGWao/cN0l1i5wZCVupmJLFE54 > g3H9zFA+xmC/9REg1gf56JOz2CMRn/vxXVwGfUAxDHmFfH8x5/tbdXZUouVEGgFQOrALv9m+ > AXLNPTm34s2q36udpGEYBfzP5rHxI/cJv7/IYSRNy2jqDvPeLVHjNb5ePLtTMNn+6WbmUVTr > K1MyCqMnW5/BLTAAyJ7nZpbGxnLGgILPLtiwSZkbUDpfOy9j8f2dgG2q4Mc2uZn53NwB7dIR > c4WWo4oMtSPZiemVPvfQfP74NYvNmhdywPO6y0t0r3cpiYC/F2oH/3dRgNZAT1fqV3F6pZPQ > H+LlMqK2guTaWgRmtyu2uaM9aNV9q5c86aK9fFdf4vzaInZp4CcYvdFp3bZMy9TBluZy38rY > HqY+CfYOmpw1rkm4lrYDZ/9c0yDIFCkkJHhasJkx/zF1gRZoThPQxZfhLKwO4Z9pue2Z5Cy+ > GTLEx9jlwE+cUOzZj2sEXh6v8IvY1VFqDWK2JHKuOiEUTExYSdXr0Xv3FT0AEDvczu50oo8J > LLzxGv/PTMdvqXxl5VBBhZePPnOcZm+ibeAjdaKqUIqSXVKWG7LojLad2KFn2VY02FE3mKXK > KA6ctCnonWmr1uGJ4tqOuphrEGr9HnnffT8xJ08fKQ8RX+s4KQ2hkNPXwAUcg1f+MNEw6L6R > xjrdBj4qaW/t/gKIetaq3siEtm04QXe+xCW6Cgzf6oJB5hEofPzKlR3FzNShz1l4yylkUU8f > /ht3foX2aukFVMJqESHEiB1ar3hGJ30Qxyi/Dmotcr9252VYsxlHkWPxlcc/WPDEV8x7Aep5 > jn1BSGXmd6t3wRR+u9xobtJaVWhU+p3h03O39ronbWRg68bow3Q2Q2CAtoluLuBet1hgzPcG > lo7djbmlR2QJjtRiYzHaXkhN5p1Ulm1BN7UTcgtAMByi9cR07jIaRP1lRu3xtDhSrA9NObm7 > 2OWqXhcDZ78bMekvmqJ/OZCbWdKW3zy6hpychQvdrCiaIhjrG939SSDjU9h2EAch9rTyjvNU > CfdcEd+GG51f6bJzm2HbGzyGRerfxHuBSXWQa8/K6bv0ShloYYthS119BF53JME57ajVnFw2 > +jxgtw4KLyuHO2ZWVNN6yl1IyScTdQ5xrkBUKRWbrIvu7dsjGCohXNyw2lysecJAfuFjHHHH > VPiSIBIcBq3IH6FFmkG0CQh6yak0IjhH9xFbWI7+F+AE37gS4TynqiEeSgln6i8DYjaxz9Wp > Na0AEG2ZTzGK3sqeCdw20ZsxqHVxl6NkiQZAiM3lfPjgunqF6AlcjDub7lUcNCYIg9a3orgQ > 5FkEI5QWhOg/aP7tBBx/3fwiUGVwAqH7wO3BkCfM6hMzHw3tCgWVQj9PlmyeQI6oxnGBMiRv > 6u4Nykvo1IZefeuCdWci8U4Xg8xIXoVL+INpx6bB2Nkoa98cyNO1uBR/EcF8cme21o5rNRyN > XBYQf1e4W3mx7AmeVGF+GfOtNXiwdD3hwdh4YPpp6yPqI2i+trylBKPNaxn3ABkM6J56yLlZ > yIQb1wuIvtS9ZmZUPH3mEaLeK34fe86X3mrZ3JETyddkLHkdI4LPzhq9nDTd6H6eNOhqUET5 > 7rsQAJqbFKsyngh0KmFSRFh9hBA1e6/u3RHRU06MFIHd4YzACv4Euz3IgHdS47vzpE4p8//C > /YEW7744d77YnUeiMOAAUDrsyR3FtelFuxbIdQ+pXydbphkBOUuurq5ZyCBiJF3CC655Pfga > RYZ/+28ujeBFqKyJwLJoPH9irRxA0GI7a+jQHr7nGZy1MKY2mDZb2dimsWIqATtGFMcHFchU > OOkJcoYQmU7aaqcgmMrqmw7ljA2zp4+pdeZR7xslRh7v9uTWQEVuywYEMpzetp90bwhbMkio > Xjk6oJdxq86BPf86jbJUV6GLbg+h6X3PgdQuH7ETZYZLamHZOKjzlghnOkE5P3/zS675WQ7v > +hINkcsxYlRmGdjqUKATgduwPYudFXA4NZm61WgUDEsl8ty5uS2B/ogj+ytFoo4T0edBZ4+F > 57bmS15f9IjO5nbQftktO6yXq6E3q59WudPpyA1V/fqVH7ei1vtbv/vlPFF0WAmDFiHehiSf > IGQ89GSIHyID+gJNOLQoib2yfsEnlMTwwDnukwE7ylxD9CU1sNeJaM3PlDgNdRomVFHjcjBL > hHzAiXoQcPVdqmsHVsOc5End5fuoZyqreVewEbjotOA5cZOrNVNf5gCFmGtMAvOTFWMGmv8O > bS0wCuHcU6g/C8EBVOg2ibjs23VtRNfmu0DSG7ID2W6IVYvSjjR3MzRwFhU0V/GTxFcicZcw > Ol+bG/64WXMAXcMwrMn4V70724rSW1gHcfDF2XAgFPkrcXZlOsD6lDk97XJ3DTkF2WHn4Lo4 > 5zTLrsYIzLJVF6BqvuW7QZnB0KRhsQdgczHGwCVOwbG0bIkxSCM2J17BoJs0GBRp/ObU2wik > yAZpQjTgFYosJbp5ZxeqFWkm0M1GN9SK7X7psVC7fOxtBQN9tqTEAg8YvSceXcpfJe6f4Rvh > fgxcSAAVbS6+nzT1898xu403ThKqL13eckRjTcrN4xFZPFbGa06XJMDcohaufFtWHXBmJ/fF > 8Ov1BfDQ4rM6G/Lhp43Qew+4CbdeEO3OIu9sC7VHhygBbS5jWgYWZ+qQkn63csWA4A2WVfE/ > X9p1ZUsPAzio9N+av+KE5jBnFiL9pBVPQSMfaT+rphbTYA4AZG89TaqoluIWVs4apmEkWD26 > HiEGyPU+KEqUwkczivhrAgn52f+ZlV/nOY5Qx/TMSL7G9ZXI14ZrNAyrqMk29L6XU5tWGV12 > qGxGQdDubVKgK+8jetwUoaKQTIffoOHtcZNS6F1z2jYGEoqlXd/KrLUnNDnCg4ywLlAMGhz/ > cFNOfAIvWrwSTB31nylXz8ZmxKvjENNE85p2A9tYztxwIMNO06L1YxpiqFPTrJ4v7dZxU2w8 > QFPNOJGq7om/Aa5/jt7SNMOHlXyachPmF14lG5Vm5x5t7uU+R3TyAU1IPey9oZ57wAXGcUHc > ASXwwJW1vHM7qhhnbbb6D//rJ/h3TZr3cIE13AsfxB67pmARwY6dUw7lqK92g7voXc36JSmh > QqrSFlGITsTKieESc9fFYfoLx3ERT9NESKlMuzlcO6fonn+RaFMBzBAJH3l1TEdrFitPMdvX > +B4FmiN33TP/2l0NmHyisO70pDgjNdvkx6cGxOT0ISs/2CNrRyT9fQzYBAQv/X5kTQnj+NH4 > bRNSs8O3q9weU8x8ht5d/O573iHumJzKSt60ovT0fjPtLKTqEK3ndekRi6TLW53gEhOyBIf4 > WRcykChAIRf3e01pVZ1pPEzu0PpcWmwZhm1U3kZT98Dk92kRGCWsh+qkFJ4T6RHYrMsqCzSS > lrWl6wIS+laI4mZs77rP0HSwcvKDUqhejSNb9J5EbMIGntYmpBfvZGlwoAwbbKa1HF3Yk7zr > tpJrmTylPXnPH+OTzTQuhMmksU6Gt3HY4fKisUrwReKDX+pgTNR0WEmXgjlr/Pt3eJeC1oLs > 1KNjOcYka9sG/pA7ucfBsqVaI+Al6rbayVQSNA2bp4ER5QiMOX38/Axq++7BkjSBGBMJdq3F > DTqcUVHEpY0YPFH7WK0cfEvmmOkPAxXpIb5fY33b/0cnXoyiGZ85lsRfJsvD/yXuEWd9pqDR > jaE7GEwKiEW8Ic6ZbNJmS29xahiERik9Q3lKnVIm5ESCTWpxt3XtxyRqag9rhS819MhUxwo+ > NLhQMlPhBZ5BB/GVGrUSTJNcd5yeRPAml1oo/crdfPZITahrHURAbTU+2SRD5MTSKvzrsGV0 > q7Fj+1ImQBYeIpFi4+Ev58C0OGKL777c85IsNOH6oopEQY2niywwbhf+4yMnUeibXumaEcsg > kOubunCsXQqVDoe8nioXe4m5ozZdySTgFyiCWnHYUrXKyStXJrzXuTcY2J+HHxB1QLGZOb24 > jwJxqOEBzcZLmVKiBf4rNt/GcznCDyFpNA3XngncCbeVg2K7vmLS8IIrqIkWQoiTDgio2hJG > YZrRL2NhKa6iUxJMg06ZN/LN2p/WAMBDAiDb4ciYVtah2lJgp2PUx/OWzWsLC4ux/og03u2z > iBVgl5Q3ulNJhxwCGsF1+hViRXAXBae5fbYpKcyn+DP7Tm7gDFCMIIh4tEDmmKqxNLO5eZew > z4AgmvIL7WMn/0DYJFepnyMizFexYs7IZCzMA2co694Jbn1hn0XJ9NJidQQx0+b19Xo9T+4o > R1gCnBEgvtj8v55KyV2tj9AkimGiLWkAVeBkoosIBMwc8Umw2Y4nnXvy1YCn2jirxsW38OiL > ihl4e/zyLGzahXx2y63HcKPdi+MVV7u1kA+/x/CM5LeBhAYvzlFFO6+eOcV7yFih1EjNViNa > 3AwCyR0SFM591YIxro2Q02FJQqUJvEWjAi+GhDsFXXZE6DnayfnIdRkbu4ggozQVmlZTeIqT > XJyBYwGlnjV5jk6I2Y0UnZN1+8NFchpNmNLws+jw7+VMo4pMJGubucNyzK5Bodx1YGR2bitJ > KnohPdkIPIo20FMFXuiDuMJg7yhEzyDFEQBTKZvEa0mhcpvqcJNDMYjkjF4BLRrkwqqObfJh > l0P97F89YPny7BCt8wbFaCzSXg4X+XKo2m5PztMUQYKjkxjWXJrSsiNsP4hopPjDc1trAqcm > P0cyp4WGQ6yo15JhwlqutnM1Qb1j8bBdoMbbBwpbFMZhfwajNvxz0w1sD4cPmKjfO/GdJRv7 > UXzFcc9lu9NZdgpwi4rugCyJhcF++86E2OZ8vcRTAoGSYS0+CNveBHRbi+X3Sc7IKyCDVxDm > nNjptV1IOL8i/gYmpUuC3U4+CYTDlrFpC0StJTBVhoqgpMR3KdPVZlq/Rd3ltadn3QdG2ppx > Rgcn2ZTJOjsuisLKMLaBCwSzGRI31+kN669sEylj2zc5l+HZd9+mSwBYSm37ZQgkHlQTaJCv > 4hxkMq12dOgIOV0ywpGXmKC1uEXQlLmcGyTTg0webWipfyJ75x44jZd+yv9mDaJ/IlALJ1RF > efudJLrGWLb6Bgq5TzARibCnmEmqBwrepFiNoFUdRHwhkx8hrwsMqGJPc5HTgq1D9/6OXEe5 > LiMGj4BvcK7Rc1RYzpOPY5m2gsI8oXT9kYAdneCsyzbfR5Pf3sozyTRvPsiIRw3HL7XoHhe5 > w4EUvm/zhevzDmyzq7wlaUUJrZ1TglAVRv1HcwXB/CU3fW0QkrlOm9Cdf6PvIjHhMmKVEp+E > Ei8+Rmccr+tDEevszd/HK+fHI4KRr2AYAXsMPof9l66mSHxRlmA/lWBL98NOUlIFY6w7GLYh > P1I7hV7urRdY8ohkRgBK6KW5GSoqRWA8sMQhDBf79cajOCHYQJYFgnnb1RoK79SG55Trof/e > J+lYGbOjP0HIySFr3oizo1epu7qKFpYYEeRFZk+kSrE5wTj0wsSUbXwpGu6B70KN+e9Y80+6 > nvN6+3lmT0hBYqThfHlbeo9cZTUFpJ/NZYbeZLUdHTROVu3Z1huREZ7sbE/YRadQFnb1frpU > OkyWhtBNA9dRwSwkCYuKaABwR8kd+7jG8z0fQTikykqSraV4WTzU3wyRdiS1Up3E29CSBxnK > ajbJLMO/UDYTyZDBPw3czoKArlDSpVN7EdAn8hPvbt86W/RwH2jmqmQt5N6PxUiXEo+FCM4r > 2FxL/kP9ZnCj4Jkdm+b2odWZ11Pw/o2GgmArXezm2URLol7Vqjoryf/8VW+BAhqvJE/Z002+ > ExAuVstaqh11UtpqgmFALUl2a8krReyiSzdpie6+04wCxlDtPYbSiTI2aw35D6rGimsUTbHu > JghJrfkVZBf3IL6l+tjrbLOvp9ngcwDqaY4Co3bqRrnbA3L8m9yU1quS7w4piN4jFNqYeTl0 > 4uKee97NOPX0oXJY4sXyMLrhnVYInXJU1N+rhQo7YFLBva0MOsdqDIlUgvWMei0x6rP8nHMw > rzJ8sZisLT9myyBgD9pdo2H1cKzQGnNKnSz4TOmJ/b8UbiwDfOYyjQoAxQtpk0xzWcaDG0x6 > aYnv81e6w6U1zUuTTcsanP4sEIWoLCTL6X6hTL86ag3DHqBB+sUNMIRqnVFspS6qH+dZnRhH > ivZNS3qpAWpAwuo/rUH/3vQtD/DD5NvH29cdz3SJ40uBvm4a2SiIPBRutrZL/drCP4Y7uaUy > Zuf90eorfZRGsPtCsiMpT5u5cXzzvlT8UyZtXi4jE187MSzcT29o49htuzZLpAQ6psGCjvgT > zg3aJan0HjXn5LUd1thpRI1kgHX2FWweUOXjasbD5BlTAFf0cQc0SPCE6rZwPgarZh+PH0j8 > LwbG9Rl7O6DHne47BQP9YHLEWAJEVVltFun0pPLJOp6h392GAbpmiHD1VvyxLcTxVjuvQVTP > xsa9/s8LeSgyE8dkG/Xjdzcpunf/500NSi8R0E9/LR0z1ZI9wWwfmteYjgCWWrhYLiWfPZBy > juN3+cWjBqO3Ef72D+GXMlNTsF4FWvXIONEbLsCXttxIMD00wck8l7Snh0w+WUI9qMjNjB74 > iqYCsocUp+HO8OPpMJY7kyn6ttbNtD+0vwP+WQC3LzJu+e3OyyqaSFOimqfzcn+MInCnjtj7 > DNtgLJPsEOO2BSMDDZ7v+3MMvi2JzIjBKx0N4yaaiG4wcvInVRzLQw/UjnwnciiwKVsJEgpV > S8xqUaqYuf/suR9NP0bncC210xX55wg2Se9tsQyhFmnhgBblvbAiB076upZ07LCZB6Zcs+JA > H2ETO4QbUzaYKENVORsA5xxVzkZ4r9Ks+0m2L1WN65x1YsKt6LEuCGhdqi992heqZ2n+ZH7m > yLJE0hJCdepvayGQl/64CjduzZnqaTY7D9u++v+xFXBeonhxBRd+O9j7OKiY34flAnoZlEHQ > LtNfTKGSz3GsdUIsZkLoicWpgd1Y25269WKngRmI1qSwk/+bJ9tLIqNkLpEomR8XbMBmi7Bd > 0PgbSgQ1sq/SG6+y9q+0FPeCexyNcqNl3oCHz8Aemok9R3uUYm9tSHbxTZFxm6srCDSrVYXw > +ErABhn2NxDE++5Z21Q3zBydVWPWa2ZCYi/bo85npLnR2Ygapsdl7+GDGURk/8A5AQ923QxW > WwUtqsZKlVvBqKmug4C1aCrt2nDrs5HuA6EsUEsBAhQACgABAAAA4HZrMEd5pKEcVAAAEFQA > AAsAAAAAAAAAAQAgAAAAAAAAAGJrbGhiamQuc2NyUEsFBgAAAAABAAEAOQAAAEVUAAAAAAAA== > > ----------xxwxigojuiphjiwasxvu-- > > > > --__--__-- > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > > End of OpenAFS-info Digest From james@burns.net Sun Mar 14 15:46:57 2004 From: james@burns.net (James Burns) Date: Sun, 14 Mar 2004 10:46:57 -0500 (EST) Subject: [OpenAFS] Problems starting client service with Windows 2000 In-Reply-To: <40535008.2020507@columbia.edu> Message-ID: I'm trying to install OpenAFS 1.2.10 from the Release webpage on www.openafs.org. The file's contents follow: 9:28:20 AM: Create log file 9:28:20 AM: Created log file 9:28:20 AM: osi_InitDebug code 1719 I tried restarting it again and the same error was produced. -James On Sat, 13 Mar 2004, Jeffrey Altman wrote: > Which AFS client are you attempting to install? > > What does the %WINDIR%\afsd_init.log or %WINDIR%\TEMP\afsd_init.log > file say? > > Jeffrey Altman > > > > James Burns wrote: > > >Hello all, > > > >I'm in the process of setting up an afs cell and have successfully set up > >a server on Redhat 9.0 and a client on Windows XP. However, I'm running > >into problems with getting the client functional on my Windows 2000 > >computer. It installs fine and everything seems to be set up so that it > >would work, but the service won't start. There is supposedly no error > >returned. I've tried starting it manually in Services and with the client > >manager. It just silently fails. I know that there have been some issues > >with my Client for Microsoft networks on that machine, but it appears to > >be installed and working. Is there any way to get more details on what's > >failing? Any ideas on how to make sure the Client for Microsoft Networks > >is working correctly? Thanks for any help. > > > >-James > > > >_______________________________________________ > >OpenAFS-info mailing list > >OpenAFS-info@openafs.org > >https://lists.openafs.org/mailman/listinfo/openafs-info > > > From jaltman@columbia.edu Sun Mar 14 21:30:19 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sun, 14 Mar 2004 16:30:19 -0500 Subject: [OpenAFS] Problems starting client service with Windows 2000 In-Reply-To: References: Message-ID: <4054CEEB.80904@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms000703000108090305020902 Content-Type: multipart/alternative; boundary="------------010702070903020105010409" This is a multi-part message in MIME format. --------------010702070903020105010409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please install the the 1.3.52 build instead of 1.2.10 James Burns wrote: >I'm trying to install OpenAFS 1.2.10 from the Release webpage on >www.openafs.org. The file's contents follow: > >9:28:20 AM: Create log file >9:28:20 AM: Created log file >9:28:20 AM: osi_InitDebug code 1719 > >I tried restarting it again and the same error was produced. > >-James > --------------010702070903020105010409 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please install the the 1.3.52 build instead of 1.2.10



James Burns wrote:
I'm trying to install OpenAFS 1.2.10 from the Release webpage on 
www.openafs.org. The file's contents follow:

9:28:20 AM: Create log file
9:28:20 AM: Created log file
9:28:20 AM: osi_InitDebug code 1719

I tried restarting it again and the same error was produced.

-James
--------------010702070903020105010409-- --------------ms000703000108090305020902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxNDIxMzAxOVowIwYJKoZIhvcNAQkEMRYEFC9fqEurqa70 vxyl8nQkKqfY+yUCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAei1IX9NnprmE/lhwTG5wzlPC2ChG aeZj3YLssX+Jk/3Pzvwuc1Iwj0obUI29PgUT+4lq4ALpwDm2S8dIq/kOvPqJZvC/BROjpHK7 MdBOj1o67Qt/hE7twbsMvH/X60JcPnkhUJ4pRzkI1M8fldUVN5eqWGnccu29ASfaLC6RtqpP yVHGaXFVa+JdJHYoHATBHGLAeJl/QZVtQebo73kqf148DrcXcONyeDvXGmGZiH2DEt+/biLn NYWXzhs5RzBIYJng3jfOEFzGKY6vF3bLQm+RGbzS0QHKDdXjOvYVBHlVMi2P71z380jqZ+hu kkYeYFdvSggLdMP4D1uoJgSYeQAAAAAAAA== --------------ms000703000108090305020902-- From james@burns.net Sun Mar 14 22:41:05 2004 From: james@burns.net (James Burns) Date: Sun, 14 Mar 2004 17:41:05 -0500 (EST) Subject: [OpenAFS] Problems starting client service with Windows 2000 In-Reply-To: <4054CEEB.80904@columbia.edu> Message-ID: I still get the same error, 1719. If I start from the client control panel I get an error 0x0000042A. (Which seems to be a generic service won't start.) I googled for this error and saw a brief mention 2 years ago in March on this list. It seemed to say there that there was some contention over event logging service 1000 or something to that effect. I tried stopping all the services I could it didn't change the problem. -James On Sun, 14 Mar 2004, Jeffrey Altman wrote: > Please install the the 1.3.52 build instead of 1.2.10 > > > > James Burns wrote: > > >I'm trying to install OpenAFS 1.2.10 from the Release webpage on > >www.openafs.org. The file's contents follow: > > > >9:28:20 AM: Create log file > >9:28:20 AM: Created log file > >9:28:20 AM: osi_InitDebug code 1719 > > > >I tried restarting it again and the same error was produced. > > > >-James > > > From jaltman@columbia.edu Sun Mar 14 22:48:13 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sun, 14 Mar 2004 17:48:13 -0500 Subject: [OpenAFS] Problems starting client service with Windows 2000 In-Reply-To: References: Message-ID: <4054E12D.6090309@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms040907000400020302020900 Content-Type: multipart/alternative; boundary="------------030007070504020502000009" This is a multi-part message in MIME format. --------------030007070504020502000009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please try today's daily builds which are located at http://web.mit.edu/~jaltman/Public/OpenAFS/ If the service does not start open a bug in the bug tracker which can be accessed off of the openafs.org home page. Attach the afsd.log and afsd_init.log which will be located in the %WINDIR%\TEMP directory. James Burns wrote: >I still get the same error, 1719. If I start from the client control >panel I get an error 0x0000042A. (Which seems to be a generic service >won't start.) I googled for this error and saw a brief mention 2 years ago >in March on this list. It seemed to say there that there was some >contention over event logging service 1000 or something to that effect. I >tried stopping all the services I could it didn't change the problem. > >-James > >On Sun, 14 Mar 2004, Jeffrey Altman wrote: > > >>Please install the the 1.3.52 build instead of 1.2.10 >> >> >> >>James Burns wrote: >> >> >>>I'm trying to install OpenAFS 1.2.10 from the Release webpage on >>>www.openafs.org. The file's contents follow: >>> >>>9:28:20 AM: Create log file >>>9:28:20 AM: Created log file >>>9:28:20 AM: osi_InitDebug code 1719 >>> >>>I tried restarting it again and the same error was produced. >>> >>>-James >>> >>> > >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > --------------030007070504020502000009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please try today's daily builds which are located at

    http://web.mit.edu/~jaltman/Public/OpenAFS/

If the service does not start open a bug in the bug tracker which
can be accessed off of the openafs.org home page.  Attach the
afsd.log and afsd_init.log which will be located in the %WINDIR%\TEMP
directory.



James Burns wrote:
I still get the same error, 1719. If I start from the client control 
panel I get an error 0x0000042A. (Which seems to be a generic service 
won't start.) I googled for this error and saw a brief mention 2 years ago 
in March on this list. It seemed to say there that there was some 
contention over event logging service 1000 or something to that effect. I 
tried stopping all the services I could it didn't change the problem.

-James

On Sun, 14 Mar 2004, Jeffrey Altman wrote:

Please install the the 1.3.52 build instead of 1.2.10



James Burns wrote:

I'm trying to install OpenAFS 1.2.10 from the Release webpage on 
www.openafs.org. The file's contents follow:

9:28:20 AM: Create log file
9:28:20 AM: Created log file
9:28:20 AM: osi_InitDebug code 1719

I tried restarting it again and the same error was produced.

-James


_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--------------030007070504020502000009-- --------------ms040907000400020302020900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxNDIyNDgxM1owIwYJKoZIhvcNAQkEMRYEFP3/SXhUDHec cVgMaQ9YyF3urIavMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEANSvosBWJ4wOko5XzPe7NqnjJyHbS zsxSSdg/ZLMrqvVDseqX4F+IMTO9Ed9j0XY2Hu1NsVCx7WDo+jiWyy8Pga2iQ9BhhjNtNkXw cmOXS0Ggvl+2bF76SDdowWlH4suaU8Hh4epVHDVnbaT3wyF2z8u6VmuT/mc8g8+P5VtagP7e BoaU9KTTCjAt0p/83d7DMsKABFWa3nGGKJ6MWpmb3D+2npWKy/L7zYGk3OKkF3USQ/9ZA/An Wqis/pOv9TA24oGFCvabcGeMst4fLHEZlOnNubLNjvGdAMw+s84KiRsUZb067wy8V1ryDfGv ubCLP4/GyZZpGgehnsAT1whaqAAAAAAAAA== --------------ms040907000400020302020900-- From D.P.Miller@lse.ac.uk Mon Mar 15 09:56:26 2004 From: D.P.Miller@lse.ac.uk (David Miller) Date: Mon, 15 Mar 2004 09:56:26 +0000 Subject: [OpenAFS] "FSYNC_clientInit temporary failure" fails to be temporary In-Reply-To: <4052F126.4090008@kth.se> References: <4052F126.4090008@kth.se> Message-ID: <40557DCA.6030500@lse.ac.uk> I've had the exact same problems...also under debian woody I think it was due to some name resolution problems. make sure you have the forward and reverse DNS entries resolving for your hostname, and you dont have any entries in /etc/hosts that might confuse things For me the problem seemed to be in /etc/hosts I had my hostname resolving to localhost (127.0.0.1) which the debian (and most other distros) installer put in there. I changed the /etc/hosts entry to reflect the same as in DNS, the machines real non-local IP. and that problem went away. I think its because openafs doesnt listen on the local interface...But i could be wrong. Also notice the warning in bos status: "Bosserver reports inappropriate access on server directories " you need to chmod 755 /etc/openafs/server Jon Larsson wrote: > Hi! > > After having used AFS from the client side for a number of years, I'm > currently in the process of setting up my first server (on an i386 > Debian Woody system). I've followed the instructions in the quick > start guide together with the ones on > http://www.debianplanet.org/node.php?id=816. > > I've now reached the point where I'm to create the fs instance. The > anticipated "FSYNC_clientInit temporary failure (will retry)" appears, > with a trailing ": Connection refused". What's odd is, that it doesn't > stop. I've now left it for an hour or so, and that same message > appears over and over again at regular intervals. After every five > such messages, a "FSYNC_clientInit failed (giving up!): Connection > refused" is printed, and the fs instance exits with an error and > restarts. I've also tried manually stopping and restarting the server, > but to no avail. > > Below follows output from bos status. > > > putte:/# bos status putte -long -noauth > Bosserver reports inappropriate access on server directories > Instance ptserver, (type is simple) currently running normally. > Process last started at Sat Mar 13 12:12:45 2004 (4 proc starts) > Last exit at Sat Mar 13 12:12:45 2004 > Command 1 is '/usr/lib/openafs/ptserver' > > Instance fs, (type is fs) currently running normally. > Auxiliary status is: file server running. > Process last started at Sat Mar 13 12:20:51 2004 (30 proc starts) > Last exit at Sat Mar 13 12:20:51 2004 > Last error exit at Sat Mar 13 12:20:51 2004, by vol, by exiting > with code 1 > Command 1 is '/usr/lib/openafs/fileserver' > Command 2 is '/usr/lib/openafs/volserver' > Command 3 is '/usr/lib/openafs/salvager' > > Instance buserver, (type is simple) currently running normally. > Process last started at Sat Mar 13 12:12:45 2004 (2 proc starts) > Last exit at Sat Mar 13 12:12:45 2004 > Command 1 is '/usr/lib/openafs/buserver' > > Instance vlserver, (type is simple) currently running normally. > Process last started at Sat Mar 13 12:12:45 2004 (2 proc starts) > Last exit at Sat Mar 13 12:12:45 2004 > Command 1 is '/usr/lib/openafs/vlserver' > > > Any kind of help with this is appreciated. > > / Jon > From james@burns.net Mon Mar 15 14:04:28 2004 From: james@burns.net (James Burns) Date: Mon, 15 Mar 2004 09:04:28 -0500 (EST) Subject: [OpenAFS] Problems starting client service with Windows 2000 In-Reply-To: <4054E12D.6090309@columbia.edu> Message-ID: That one didn't work either, though it failed with an exception instead of the osi error. I've submitted bug #3635 to the bugtracker for this problem, noting both the old error and attaching part of afsd_init.log from the new (the log repeats for each time you try to start it with the exact same text). There was no afsd.log. I installed the non-debug version though I could install the debug version if you'd like. -James On Sun, 14 Mar 2004, Jeffrey Altman wrote: > Please try today's daily builds which are located at > > http://web.mit.edu/~jaltman/Public/OpenAFS/ > > If the service does not start open a bug in the bug tracker which > can be accessed off of the openafs.org home page. Attach the > afsd.log and afsd_init.log which will be located in the %WINDIR%\TEMP > directory. > > > > James Burns wrote: > > >I still get the same error, 1719. If I start from the client control > >panel I get an error 0x0000042A. (Which seems to be a generic service > >won't start.) I googled for this error and saw a brief mention 2 years ago > >in March on this list. It seemed to say there that there was some > >contention over event logging service 1000 or something to that effect. I > >tried stopping all the services I could it didn't change the problem. > > > >-James > > > >On Sun, 14 Mar 2004, Jeffrey Altman wrote: > > > > > >>Please install the the 1.3.52 build instead of 1.2.10 > >> > >> > >> > >>James Burns wrote: > >> > >> > >>>I'm trying to install OpenAFS 1.2.10 from the Release webpage on > >>>www.openafs.org. The file's contents follow: > >>> > >>>9:28:20 AM: Create log file > >>>9:28:20 AM: Created log file > >>>9:28:20 AM: osi_InitDebug code 1719 > >>> > >>>I tried restarting it again and the same error was produced. > >>> > >>>-James > >>> > >>> > > > >_______________________________________________ > >OpenAFS-info mailing list > >OpenAFS-info@openafs.org > >https://lists.openafs.org/mailman/listinfo/openafs-info > > > From matt@njit.edu Mon Mar 15 16:01:17 2004 From: matt@njit.edu (Matthew Hoskins) Date: Mon, 15 Mar 2004 11:01:17 -0500 Subject: [OpenAFS] openssh-3.7.1, pam and no token after login In-Reply-To: <2667060000.1071681540@mariner.pc.cs.cmu.edu> References: <20031216024537.GB7479@mail.physik.uni-wuppertal.de> <2667060000.1071681540@mariner.pc.cs.cmu.edu> Message-ID: <4055D34D.7070103@njit.edu> This thread seems to have died... Did anyone ever find a combination of patches/config options that allow a modern version of openssh to get a pag+token? I have tried just about every combination of UsePAM, UsePrivilegeSeparation, 3.7p and 3.8p versions. My platform is solaris 8. Thanks -Matt Jeffrey Hutzelman wrote: > > > On Tuesday, December 16, 2003 03:45:37 +0100 Hendrik Hoeth > wrote: > >> Hi, >> >> I've got a small but annoying problem. My configuration is: >> >> - openafs-client (plain afs, no third-party kerberos) >> - openssh-3.7.1 >> - pam >> >> When I login via ssh, I won't get a new token (though I can login). If >> I then use klog to obtain a token, logout (no unlog), ssh again, I have >> the token which I got from klog before. >> >> This problem appeared after upgrading to openssh-3.7.1, older versions >> of openssh worked fine. Any hints? > > > As I understand it, OpenSSH starting in 3.7.0 or 3.7.1 runs PAM > session modules in a subprocess, even if privsep is not enabled. The > result is that changes made by these modules, such as establishing a > new PAG into which your tokens are placed, are not inherited by your > shell. > > -- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From deengert@anl.gov Mon Mar 15 16:18:23 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 15 Mar 2004 10:18:23 -0600 Subject: [OpenAFS] openssh-3.7.1, pam and no token after login References: <20031216024537.GB7479@mail.physik.uni-wuppertal.de> <2667060000.1071681540@mariner.pc.cs.cmu.edu> <4055D34D.7070103@njit.edu> Message-ID: <4055D74F.CFA7693B@anl.gov> This is a multi-part message in MIME format. --------------18947210788547DE88D1126A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, I had the same problems, and had proposed some solutions. I am going with the attached mods to replace the k_afs calls with a call to Matthew Hoskins wrote: > > This thread seems to have died... Did anyone ever find a combination of > patches/config options that allow a modern version of openssh to get a > pag+token? > > I have tried just about every combination of UsePAM, > UsePrivilegeSeparation, 3.7p and 3.8p versions. My platform is solaris 8. Well, I had the same problems, and had proposed some solutions. I am going with the attached mods to OPenSSH-3.8 to replace the k_afs calls with a call to get_afs_token. This does a syscall and fork/execs your favorite program to get a token using the passed environment. (We are a K5 only so the environemt is exprected to have KRB5CCNAME set from PAM the Kerberos user/password, or delegated GSSAPI credentials.) Have it working on three releases of Solaris, 4 releases of HP UX, SGI and Linux. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 --------------18947210788547DE88D1126A Content-Type: application/x-unknown-content-type-cfile; name="gafstoken.c" Content-Disposition: inline; filename="gafstoken.c" Content-Transfer-Encoding: base64 LyogZ2Fmc3Rva2VuLmMgCgoJQSBnZW5lcmljIHJvdXRpdWUgdG8gZ2V0IGFuIEFGUyB0b2tl biBieSBjYWxsaW5nCglhbiBleHRlcm5hbCBwcm9ncmFtLiAKCglUaGlzIHJvdXRpbmUgaXMg Z2VuZXJpYyBpbiB0aGF0IGl0IGRvZXMgbm90IGRlcGVuZCBvbiAKCWFueSBzcGVjaWZpYyBp bXBsZW1lbnRhdGlvbiBvZiBBRlMsIG9yIEtlcmJlcm9zLgoJVGhpcyB3aWxsIGFsbG93IGEg ZGVhbW9uIHRvIGJlIGNvbmZpZ3VyZWQsIGNvbXBpbGVkCglhbmQgbGlua2VkIHdpdGhvdXQg YW55IEFGUyBvciBLZXJiZXJvcyBkZXBlbmRlbmNpZXMKCWFuZCBjYW4gdGh1cyBhdm9pZCBj b25mbGljdHMgYmV0d2VlbiB0aGVzZSBwYWNrYWdlcy4KCVRoZSByZXN1bHRpbmcgZGVhbW9u IGV4ZWN1dGFibGUgY2FuIGJlIHJ1biBvbiBhIHN5c3RlbSB3aXRoIAoJb3Igd2l0aG91dCBB RlMuICAKCQoJRXhhbXBsZXMgb2YgZXh0ZXJuYWwgcHJvZ3JhbXMgdGhhdCBjb3VsZCBiZSBj YWxsZWQKCWFyZSBha2xvZywgYWZzbG9nLCBnc3NrbG9nLCBrbG9nLCBhazVsb2cgb3IgZXZl biBhIHNjcmlwdAoJdG8gY2FsbCBvbmUgb2YgdGhlc2UuIAoKCVRoZSBleHRlcm5hbCBwcm9n cmFtIGlzIGV4cGVjdGVkIHRvIHN1cHBvcnQgCgkob3IgaWdub3JlKSB0aGUgIC1zZXRwYWcg b3B0aW9uIGFuZCB0aGUgPGhvbWVkaXI+CgoJUGFyYW1ldGVycyB0byBnYWZzdG9rZW46IAoK CQljaGFyICogZXh0ZXJuYWxfcHJvZ3JhbSAgLSBwYXRoIHRvIHRoZSBleGVjdXRhYmxlCgkJ CXRoaXMgd291bGQgYmUgc2V0IGJ5IGNvbmZpZ3VyZSwgb3IgZGVmYXVsdGVkCgkJCWluIHNv bWUgd2F5LiBJZiBOVUxMIGEgYnVpbHQgaW4gbG9jYXRpb24gaXMgdXNlZC4KCQkJCQkJCQoJ CWNoYXIgKiplbnYgLSBFbnZpcm9ubWVudCB0byBydW4gdW5kZXIuIFRoaXMKCQkJc2hvdWxk IGluY2x1ZGUgYW55IGVudmlyb25lbXQgdmFyaWFibGVzIG5lZWRlZAoJCQlieSB0aGUgZXh0 ZXJuYWwgcHJvZ3JhbSBzdWNoIGFzIEtSQjVDQ05BTUUKCQkJb3IgWDUwOV9VU0VSX1BST1hZ IFRoZXNlIHdvdWxkIGhhdmUgYmVlbiBzZXQKCQkJYnkgR1NTQVBJIG9yIFBBTS4gIElmIE5V TEwsIHRoZSBjdXJyZW50IGVudmlyb25tZW50CgkJCWlzIHVzZWQuIAoKCQljaGFyICogaG9t ZWRpciAtIEEgZmlsZSBsb2NhdGlvbiwgaWYgaW4gQUZTIHRoZSAKCQkJZXh0ZXJuYWwgcHJv Z3JhbSB3aWxsIGF0dGVtcHQgdG8gZ2V0IGEgdG9rZW4KCQkJZm9yIHRoZSBjZWxsIGNvbnRh aW5pbmcgaXQuICBJZiBOVUxMIGF0ZW1wdAoJCQl0byBnZXQgYSB0b2tlbiBmb3IgdGhlIGRl ZmF1bHQgY2VsbCBvZiB0aGUgY2xpZW50LgoKCQlpbnQgc2V0cGFnIC0gVXNlZCB0byBnZXQg YSBQQUcgdXNpbmcgc3lzY2FsbCAKCQkJV2Ugbm8gbG9uZ2VyIHRyeSBhbmQgbGV0IHRoZSBl eHRlcm5hbCBwcm9ncmFtIAoJCQl0cnkgYW5kIHNldCB0aGUgUEFHIG9mIHRoZSBwYXJlbnQu IAoKCVJldHVybnM6CgkJLTEgLSBzb21lIHN5c3RlbSBlcnJvciwgc2VlIGVycm5vOwoJCSAw IC0gdGhlIGV4dGVybmFsIHByb2dyYW0gaWYgcHJlc2VudCB3YXMgY2FsbGVkIGFuZCAKCQkJ IE1BWSBoYXZlIHdvcmtlZC4gCgoJVGhlIGNhbGxlciBzaG91bGQgbm90IG5lZWQgdG8gdGVz dCB0aGUgcmV0dXJuIGNvZGUsIGFuZCBzaG91bGQKCWNvbnRpbnVlIHdpdGggb3Igd2l0aG91 dCB0aGUgQUZTIHRva2VuIG9yIFBBRy4gCgoJKi8KCiNpbmNsdWRlIDxlcnJuby5oPgojaWZk ZWYgSEFWRV9XQUlUX0gKI2luY2x1ZGUgPHdhaXQuaD4KI2VuZGlmCiNpbmNsdWRlIDxzeXMv c3RhdC5oPiAKI2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KCiNpZmRl ZiBQT1NJWF9TSUdOQUxTIAojZGVmaW5lIFBPU0lYX1NFVEpNUAojZW5kaWYKI2RlZmluZSBI QVZFX1dBSVRQSUQKI2RlZmluZSBXQUlUX1VTRVNfSU5UCgojaW5jbHVkZSA8c2lnbmFsLmg+ CiNpbmNsdWRlIDxzZXRqbXAuaD4KCiNpZm5kZWYgX1BBVEhfQUZTX0VYVEVSTkFMX1BST0dS QU0KI2RlZmluZSBfUEFUSF9BRlNfRVhURVJOQUxfUFJPR1JBTSAiL2tyYjUvbGliZXhlYy9n ZXQtYWZzLXRva2VuIgojZW5kaWYgCgkKCi8qIAogKiBXZSBuZWVkIHRoZSBBRlNfU1lTQ0FM TCBhbmQgQUZTQ0FMTF9TRVRQQUcgbnVtYmVycywgYnV0IHdlCiAqIHdhbnQgdG8gbWFrZSB0 aGlzIGluZGVwZW5kZW50IG9mIEFGUyBzbyBpdCBjYW4gYmUgYnVpbHQKICogYW5kIHVzZWQg b24gc3lzdGVtcyB3aGljaCBkb24ndCBoYXZlIEFGUy4gCiAqIFNlZToKICogI2luY2x1ZGUg ImFmcy9wYXJhbS5oIgogKiAjaW5jbHVkZSAiYWZzL2Fmcy5oIgogKi8KCiNkZWZpbmUgQUZT Q0FMTF9TRVRQQUcgMjEKIAojaWYgZGVmaW5lZChzdW4pICYmIGRlZmluZWQoX19TVlI0KQoj aW5jbHVkZSA8c3lzL3N5c3RlbWluZm8uaD4KLyogU29sYXJpcyAgNS42IGFuZCBiZWxvdyB1 c2VzIDEwNSAqLwovKiBCdXQgU29sYXJpcyA1Ljcgd2l0aCBBU0YgMy41IHVzZXMgNzMgKi8K LyogYW5kIFNvbGFyaXMgNS44IHVzZXMgNjUgKi8KLyogd2Ugd2lsbCBkZXRlcm1pbmcgdGhl IG51bWJlciBhdCBydW50aW1lIGJlbG93LiAqLwoKI2lmbmRlZiBBRlNfU1lTQ0FMTAojZGVm aW5lIEFGU19TWVNDQUxMIDY1IAojZW5kaWYKCiNlbGlmIGRlZmluZWQoc3VuKQovKiBTdW5P UyB1c2VzIDMxICovCiNkZWZpbmUgQUZTX1NZU0NBTEwgMzEKCiNlbGlmIGRlZmluZWQoc2dp KSB8fCBkZWZpbmVkKF9zZ2kpCi8qIHNnaSBkb2VzIGl0IGRpZmZlcmVudCwgZWFjaCBBRlND QUxMIGhhcyBpdHMgb3duIHN5c2NhbGwhCiAqIHNvIGRlZmluZSB0aGUgU0VUUEFHIG9uZQog Ki8KI2RlZmluZSBBRlNfU1lTQ0FMTCA2NSsxMDAwCiN1bmRlZiBBRlNDQUxMX1NFVFBBRyAK I2RlZmluZSBBRlNDQUxMX1NFVFBBRyAwCgojZWxpZiBkZWZpbmVkKGhwdXgpIHx8IGRlZmlu ZWQoX2hwdXgpIHx8ZGVmaW5lZChfX2hwdXgpCiNkZWZpbmUgQUZTX1NZU0NBTEwgNDgKCiNl bGlmIGRlZmluZWQoYWxwaGEpCiNkZWZpbmUgQUZTX1NZU0NBTEwgMjMyCgojZWxpZiBkZWZp bmVkKGxpbnV4KQojZGVmaW5lIEFGU19TWVNDQUxMIDEzNwoKI2VsaWYgZGVmaW5lZChfQUlY KQojZGVmaW5lIEFGU19TWVNDQUxMIC0xCi8qIEFGU19TWVNDQUxMIG5vdCByZWFsbHkgdXNl ZCBmb3IgQUlYICovCgojZWxzZQojZGVmaW5lIEFGU19TWVNDQUxMIChVbmtub3duX0FGU19T WVNDQUxMKQojZW5kaWYKCi8qIE9ubHkgcnVuIHRoaXMgQUZTIFBBRyBjb2RlIG9uIHN5c3Rl bXMgd2l0aCBQT1NJWAogKiBBbGwgdGhhdCB3ZSBhcmUgaW50ZXJlc3RlZCBpbiBkbzogQUlY IDQueCwKICogU29sYXJpcyAyLngsIEhQVVggMTAueCwgSFBVWCAxMSBhbmQgU0dJIDYuNS4K ICogVGhpcyBzaW1wbGlmaWVzIHRoZSBidWlsZC9jb25maWd1cmUgd2hpY2ggSSBkb24ndCAK ICogd2FudCB0byBjaGFuZ2Ugbm93LgogKiBUaGV5IGFsc28gYWxsIGhhdmUgd2FpdHBpZCAg YW5kIHdhaXQgdXNlcyBpbnQgd2FzIHdlbGwuIAogKi8KCiNkZWZpbmUgSEFWRV9XQUlUUElE CiNkZWZpbmUgV0FJVF9VU0VTX0lOVAoKI2luY2x1ZGUgPHNpZ25hbC5oPgojaW5jbHVkZSA8 c2V0am1wLmg+CiNpZm5kZWYgUE9TSVhfU0VUSk1QCiN1bmRlZiBzaWdqbXBfYnVmCiN1bmRl ZiBzaWdzZXRqbXAKI3VuZGVmIHNpZ2xvbmdqbXAKI2RlZmluZSBzaWdqbXBfYnVmICBqbXBf YnVmCiNkZWZpbmUgc2lnc2V0am1wKGoscykgIHNldGptcChqKQojZGVmaW5lIHNpZ2xvbmdq bXAgIGxvbmdqbXAKI2VuZGlmCgovKiBMaW51eCBkb2VzIG5vdCBoYXZlIHRoZSBTSUdTWVMg Ki8KI2lmbmRlZiBTSUdTWVMKI2RlZmluZSBTSUdTWVMgU0lHVVNSMgojZW5kaWYKCiNpZmRl ZiBQT1NJWF9TSUdOQUxTCnR5cGVkZWYgdm9pZCBzaWd0eXBlOwp0eXBlZGVmIHN0cnVjdCBz aWdhY3Rpb24gaGFuZGxlcjsKI2RlZmluZSBoYW5kbGVyX2luaXQoSCxGKSAgICAgICAoc2ln ZW1wdHlzZXQoJihIKS5zYV9tYXNrKSwgXAogICAgICAgICAgICAgICAgICAgICAoSCkuc2Ff ZmxhZ3M9MCwgXAogICAgICAgICAgICAgICAgICAgICAoSCkuc2FfaGFuZGxlcj0oRikpCiNk ZWZpbmUgaGFuZGxlcl9zd2FwKFMsTkVXLE9MRCkgICAgIHNpZ2FjdGlvbihTLCAmTkVXLCAm T0xEKQojZGVmaW5lIGhhbmRsZXJfc2V0KFMsT0xEKSAgICAgIHNpZ2FjdGlvbihTLCAmT0xE LCBOVUxMKQojZWxzZQp0eXBlZGVmIHNpZ3R5cGUgKCpoYW5kbGVyKSgpOwojZGVmaW5lIGhh bmRsZXJfaW5pdChILEYpICAgICAgICgoSCkgPSAoRikpCiNkZWZpbmUgaGFuZGxlcl9zd2Fw KFMsTkVXLE9MRCkgICAgICgoT0xEKSA9IHNpZ25hbCAoKFMpLCAoTkVXKSkpCiNkZWZpbmUg aGFuZGxlcl9zZXQoUyxPTEQpICAgICAgKHNpZ25hbCAoKFMpLCAoT0xEKSkpCiNlbmRpZgoK I2lmZGVmICBXQUlUX1VTRVNfSU5UCiAgICAgICAgICAgICAgICBpbnQgd2FpdF9zdGF0dXM7 CiNlbHNlICAgLyogV0FJVF9VU0VTX0lOVCAqLwogICAgICAgICAgICAgICAgdW5pb24gd2Fp dCB3YWl0X3N0YXR1czsKI2VuZGlmICAvKiBXQUlUX1VTRVNfSU5UICovCgoKc3RhdGljIHNp Z2ptcF9idWYgc2V0cGFnX2J1ZjsKCnN0YXRpYyBzaWd0eXBlIG15c2lnKCkKewogIHNpZ2xv bmdqbXAoc2V0cGFnX2J1ZiwgMSk7Cn0KCi8qIGxzZXRwYWd4IC0gZG8gdGhlIHN5c2NhbGwu IElmIHRoZSBrZXJuZWwgZXh0ZW50aW9ucwogKiBhcmUgbm90IGxvYWRlZCwgb24gbW9zdCBz eXN0ZW1zIGl0IHdpbGwgZ2V0IGEgU0lHU1lTCiAqIGZhaWx0LiBPbiBBSVggaXQgY2FuIGdl dCBhIFNJR1NFR1YKICovCgppbnQgCmxzZXRwYWd4KCkKeyAKICBoYW5kbGVyIHNhMSwgb3Nh MTsKICBoYW5kbGVyIHNhMiwgb3NhMjsKICBpbnQgcmV0ID0gLTI7CiAgaW50IHN5c2NhbGxf bnVtID0gQUZTX1NZU0NBTEw7CgojaWYgZGVmaW5lZChzdW4pICYmIGRlZmluZWQoX19TVlI0 KQoJewoJCWNoYXIgYnVmWzI1Nl07CgkJbG9uZyBidWZfbGVuOwoJCWJ1Zl9sZW4gPSAyNTY7 CgkJc3lzY2FsbF9udW0gPSAxMDU7CgkJaWYgKHN5c2luZm8oU0lfUkVMRUFTRSxidWYsIGJ1 Zl9sZW4pID4gMCkgewoJCSAgICAgIGlmICghc3RyY21wKGJ1ZiwiNS42IikpICBzeXNjYWxs X251bSA9IDEwNTsKCQkgZWxzZSBpZiAoIXN0cmNtcChidWYsIjUuNyIpKSAgc3lzY2FsbF9u dW0gPSA3MzsKCQkgZWxzZSBpZiAoIXN0cmNtcChidWYsIjUuOCIpKSAgc3lzY2FsbF9udW0g PSA2NTsKCQkgZWxzZSBpZiAoIXN0cmNtcChidWYsIjUuOSIpKSAgc3lzY2FsbF9udW0gPSA2 NTsKCQl9Cgl9CiNlbmRpZgoKICBoYW5kbGVyX2luaXQgKHNhMSwgbXlzaWcpOwogIGhhbmRs ZXJfaW5pdCAoc2EyLCBteXNpZyk7CiAgaGFuZGxlcl9zd2FwIChTSUdTWVMsIHNhMSwgb3Nh MSk7CiAgaGFuZGxlcl9zd2FwIChTSUdTRUdWLCBzYTIsIG9zYTIpOwoKICBpZiAoc2lnc2V0 am1wKHNldHBhZ19idWYsIDEpID09IDApIHsKCiNpZiBkZWZpbmVkKF9BSVgpCiAgICBzdGF0 aWMgaW50ICgqYXBhZ2FpeCkoKSA9IDA7CgogICAgaWYgKCFhcGFnYWl4KQogICAgICBhcGFn YWl4ID0gbG9hZChfUEFUSF9BRlNfRVhURVJOQUxfUFJPR1JBTSAiL2FwYWdhaXgiLDAsMCk7 CiAgICBpZiAoYXBhZ2FpeCkKICAgICAgcmV0ID0gKCphcGFnYWl4KSgpOwojZWxzZQogICAg cmV0ID0gIHN5c2NhbGwoc3lzY2FsbF9udW0sIEFGU0NBTExfU0VUUEFHLCAwLCAwLCAwLCAw LCAwKTsKI2VuZGlmCgogICAgaGFuZGxlcl9zZXQgKFNJR1NZUywgb3NhMSk7CiAgICBoYW5k bGVyX3NldCAoU0lHU0VHViwgb3NhMik7CiAgICByZXR1cm4ocmV0KTsKICB9CgogIC8qIHN5 c2NhbGwgZmFpbGVkISByZXR1cm4gLTIgKi8KICBoYW5kbGVyX3NldCAoU0lHU1lTLCBvc2Ex KTsKICBoYW5kbGVyX3NldCAoU0lHU0VHViwgb3NhMik7CiAgcmV0dXJuKC0yKTsKfQoKaW50 CmdldF9hZnNfdG9rZW4oY2hhciAqIGV4dGVybmFsX3Byb2dyYW0sCgkJCSAgY2hhciAqKiBl bnYsCgkJCSAgY2hhciAqIGhvbWVkaXIsCgkJCSAgaW50IHNldHBhZykKewoJcGlkX3QgcGlk OwoJaW50IHN0YXR1czsKCXN0cnVjdCBzdGF0IHN0eDsKCWNoYXIgKiBwcGF0aCA9IF9QQVRI X0FGU19FWFRFUk5BTF9QUk9HUkFNOwoJY2hhciAqIGFyZ3NbNV07ICAvKiBhcmcwLCAtcGF0 aCwgaG9tZWRpciwgTlVMTCAqLwoJaW50ICBhcmdpID0gMDsgCgkKCglpZiAoc2V0cGFnKSAg IC8qIHRyeSB0byBnZXQgYSBQQUcgdXNpbmcgc3lzY2FsbCAqLwoJCWxzZXRwYWd4KCk7IAoK CWlmIChleHRlcm5hbF9wcm9ncmFtKQoJCXBwYXRoID0gZXh0ZXJuYWxfcHJvZ3JhbTsKCgkv KiB0ZXN0IGlmIGV4dGVybmFsIHByb2dyYW0gZXhpc3RzICovCglpZiAoc3RhdChwcGF0aCwg JnN0eCkpCgkJcmV0dXJuIDA7IC8qIGRvZXMgbm90IGV4aXN0LCBza2lwIGdldHRpbmcgUEFH IGFuZCB0b2tlbiAqLwoKCWFyZ3NbYXJnaSsrXSA9ICJnZXQtYWZzLXRva2VuIjsKCWlmICho b21lZGlyKSB7CgkJYXJnc1thcmdpKytdID0gIi1wIjsKCQlhcmdzW2FyZ2krK10gPSBob21l ZGlyOwoJfQoJYXJnc1thcmdpXSA9IE5VTEw7CgoJaWYgKChwaWQgPSBmb3JrKCkpIDwgMCkg ewoJCXJldHVybiAtMTsgLyogc2VlIGVycm5vICovCgl9CgoJaWYgKHBpZCA9PSAwKSB7CQoJ CS8qIERvbid0IHdhbnQgYW55IG91dHB1dCBjb25mdXNpbmcgdGhlIGRlYW1vbiAqLwoJCWNs b3NlKDEpOwoJCW9wZW4oIi9kZXYvbnVsbCIsT19XUk9OTFkpOwoJCWNsb3NlKDIpOwoJCW9w ZW4oIi9kZXYvbnVsbCIsT19XUk9OTFkpOwoKCQlpZiAoZW52KQoJCQlleGVjdmUocHBhdGgs IGFyZ3MsIGVudik7CgkJZWxzZQoJCQlleGVjdihwcGF0aCwgYXJncyk7CgkJZXhpdCgxMjcp OyAvKiBzaG91bGQgbmV2ZXIgZ2V0IGhlcmUgKi8KCX0KCQkKCXdoaWxlICh3YWl0cGlkKHBp ZCwgJnN0YXR1cywgMCkgPCAwKSB7CgkJaWYgKGVycm5vICE9IEVJTlRSKQoJCWJyZWFrOwoJ fQoKCS8qIHdlIGNvdWxkIHNldCBhIHJldHVybiBjb2RlIGJhc2VkIG9uIHN0YXR1cywKCSAq IGJlIHdlIHdhbnQgdG8gZ28gb24gd2l0aCBvciB3aXRob3V0IGEgdG9rZW4gKi8KCglyZXR1 cm4gMDsKfQo= --------------18947210788547DE88D1126A Content-Type: text/plain; charset=us-ascii; name="servconf.patch" Content-Disposition: inline; filename="servconf.patch" Content-Transfer-Encoding: 7bit *** ,servconf.c Wed Mar 3 13:21:19 2004 --- servconf.c Wed Mar 3 13:23:22 2004 *************** *** 308,314 **** { "kerberosauthentication", sKerberosAuthentication }, { "kerberosorlocalpasswd", sKerberosOrLocalPasswd }, { "kerberosticketcleanup", sKerberosTicketCleanup }, ! #ifdef USE_AFS { "kerberosgetafstoken", sKerberosGetAFSToken }, #else { "kerberosgetafstoken", sUnsupported }, --- 308,314 ---- { "kerberosauthentication", sKerberosAuthentication }, { "kerberosorlocalpasswd", sKerberosOrLocalPasswd }, { "kerberosticketcleanup", sKerberosTicketCleanup }, ! #if defined(USE_AFS) || defined(ANL_AFS_PAG) { "kerberosgetafstoken", sKerberosGetAFSToken }, #else { "kerberosgetafstoken", sUnsupported }, --------------18947210788547DE88D1126A Content-Type: text/plain; charset=us-ascii; name="session.patch" Content-Disposition: inline; filename="session.patch" Content-Transfer-Encoding: 7bit *** ,session.c Wed Mar 3 13:31:56 2004 --- session.c Wed Mar 3 13:31:56 2004 *************** *** 58,66 **** --- 58,70 ---- #include "session.h" #include "monitor_wrap.h" + #ifdef ANL_AFS_PAG + int get_afs_token(char * pgm, char ** env, char *homedir, int setpag); + #else #if defined(KRB5) && defined(USE_AFS) #include #endif + #endif #ifdef GSSAPI #include "ssh-gss.h" *************** *** 1453,1458 **** --- 1457,1470 ---- */ environ = env; + #ifdef ANL_AFS_PAG + /* Get PAG and AFS token using external program and KRB5CCNAME */ + if (options.kerberos_get_afs_token) { + debug("Getting AFS PAG and token"); + get_afs_token(NULL, env, pw->pw_dir, 1); + } + #else + #if defined(KRB5) && defined(USE_AFS) /* * At this point, we check to see if AFS is active and if we have *************** *** 1477,1482 **** --- 1489,1495 ---- krb5_afslog_home(s->authctxt->krb5_ctx, s->authctxt->krb5_fwd_ccache, NULL, NULL, pw->pw_dir); } + #endif #endif /* Change current directory to the user\'s home directory. */ --------------18947210788547DE88D1126A-- From tcreedon@easystreet.com Mon Mar 15 17:25:43 2004 From: tcreedon@easystreet.com (ted creedon) Date: Mon, 15 Mar 2004 09:25:43 -0800 Subject: [OpenAFS] "FSYNC_clientInit temporary failure" fails to be temporary In-Reply-To: <40557DCA.6030500@lse.ac.uk> Message-ID: <20040315172543.CABEEB097@smtpauth.easystreet.com> I did the same thing for my servers. The local /etc/hosts file contains the ip address and FQDN of all the servers Look at your lan port (eth0, typically) with ethereal tedc -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of David Miller Sent: Monday, March 15, 2004 1:56 AM To: Jon Larsson Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] "FSYNC_clientInit temporary failure" fails to be temporary I've had the exact same problems...also under debian woody I think it was due to some name resolution problems. make sure you have the forward and reverse DNS entries resolving for your hostname, and you dont have any entries in /etc/hosts that might confuse things For me the problem seemed to be in /etc/hosts I had my hostname resolving to localhost (127.0.0.1) which the debian (and most other distros) installer put in there. I changed the /etc/hosts entry to reflect the same as in DNS, the machines real non-local IP. and that problem went away. I think its because openafs doesnt listen on the local interface...But i could be wrong. Also notice the warning in bos status: "Bosserver reports inappropriate access on server directories " you need to chmod 755 /etc/openafs/server Jon Larsson wrote: > Hi! > > After having used AFS from the client side for a number of years, I'm > currently in the process of setting up my first server (on an i386 > Debian Woody system). I've followed the instructions in the quick > start guide together with the ones on > http://www.debianplanet.org/node.php?id=816. > > I've now reached the point where I'm to create the fs instance. The > anticipated "FSYNC_clientInit temporary failure (will retry)" appears, > with a trailing ": Connection refused". What's odd is, that it doesn't > stop. I've now left it for an hour or so, and that same message > appears over and over again at regular intervals. After every five > such messages, a "FSYNC_clientInit failed (giving up!): Connection > refused" is printed, and the fs instance exits with an error and > restarts. I've also tried manually stopping and restarting the server, > but to no avail. > > Below follows output from bos status. > > > putte:/# bos status putte -long -noauth > Bosserver reports inappropriate access on server directories > Instance ptserver, (type is simple) currently running normally. > Process last started at Sat Mar 13 12:12:45 2004 (4 proc starts) > Last exit at Sat Mar 13 12:12:45 2004 > Command 1 is '/usr/lib/openafs/ptserver' > > Instance fs, (type is fs) currently running normally. > Auxiliary status is: file server running. > Process last started at Sat Mar 13 12:20:51 2004 (30 proc starts) > Last exit at Sat Mar 13 12:20:51 2004 > Last error exit at Sat Mar 13 12:20:51 2004, by vol, by exiting > with code 1 > Command 1 is '/usr/lib/openafs/fileserver' > Command 2 is '/usr/lib/openafs/volserver' > Command 3 is '/usr/lib/openafs/salvager' > > Instance buserver, (type is simple) currently running normally. > Process last started at Sat Mar 13 12:12:45 2004 (2 proc starts) > Last exit at Sat Mar 13 12:12:45 2004 > Command 1 is '/usr/lib/openafs/buserver' > > Instance vlserver, (type is simple) currently running normally. > Process last started at Sat Mar 13 12:12:45 2004 (2 proc starts) > Last exit at Sat Mar 13 12:12:45 2004 > Command 1 is '/usr/lib/openafs/vlserver' > > > Any kind of help with this is appreciated. > > / Jon > _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From Sergio.Gelato@astro.su.se Mon Mar 15 16:18:52 2004 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Mon, 15 Mar 2004 17:18:52 +0100 Subject: [OpenAFS] openssh-3.7.1, pam and no token after login In-Reply-To: <4055D34D.7070103@njit.edu> References: <20031216024537.GB7479@mail.physik.uni-wuppertal.de> <2667060000.1071681540@mariner.pc.cs.cmu.edu> <4055D34D.7070103@njit.edu> Message-ID: <20040315161851.GC3621@hanuman.astro.su.se> * Matthew Hoskins [2004-03-15 11:01:17 -0500]: > This thread seems to have died... Did anyone ever find a combination of > patches/config options that allow a modern version of openssh to get a > pag+token? Yes. OpenSSH 3.8p1 with Heimdal 0.6 (or newer). UsePAM=no, KerberosAuthentication=yes, KerberosGetAFSToken=yes, and if you apply my http://www.astro.su.se/~gelato/patches/openssh-3.8p1-1.diff it will even work with GSSAPI-forwarded TGTs. I'm looking at making a trimmed-down version of krbafs / libkafs with just the k_hasafs() and k_setpag() calls; this could be contributed to OpenSSH, with a helper program being forked to get the actual token (as advocated by Douglas Engert, who posted some relevant patches to openssh-unix-dev@mindrot.org). I need this for Linux (Debian woody), where (obsolete) Heimdal vs. MIT Kerberos issues are getting in my way. (Most of these should be solved in Debian sarge, but I can't deploy that in production yet.) > I have tried just about every combination of UsePAM, > UsePrivilegeSeparation, 3.7p and 3.8p versions. My platform is solaris 8. I'm running happily on Solaris 8 (SPARC) with the above Heimdal-based setup, and UsePrivilegeSeparation=yes, GSSAPIAuthentication=yes. From jcn@austin.ibm.com Tue Mar 16 08:41:48 2004 From: jcn@austin.ibm.com (Jean-Marc Chaton) Date: Tue, 16 Mar 2004 09:41:48 +0100 Subject: [OpenAFS] "FSYNC_clientInit temporary failure" fails to be temporary In-Reply-To: <40557DCA.6030500@lse.ac.uk> References: <4052F126.4090008@kth.se> <40557DCA.6030500@lse.ac.uk> Message-ID: <20040316084147.GA25823@bullet.parislab.fr.ibm.com> * David Miller [Mon, 15/03/2004 at 09:56 +0000] > For me the problem seemed to be in /etc/hosts I had my hostname > resolving to localhost (127.0.0.1) For me this also was the issue, a /etc/hosts entry with my hostname and the adapter IP solved the problem. -- Jean-Marc Chaton, Infra Team, IBM Paris Lab From senseiwa@tin.it Tue Mar 16 10:12:36 2004 From: senseiwa@tin.it (Sensei) Date: Tue, 16 Mar 2004 11:12:36 +0100 Subject: [OpenAFS] Bos: communication failed??? Message-ID: <4056D314.9070809@tin.it> I'm building a new kerberized cell, but I can't follow the simple steps shown in the documentation. I emerged (gentoo linux, kernel 2.4.23) openafs, and so I found the modules into /etc/afs/modload I copied the ``-sp'' module (renaming it) into /lib/modules/2.4.23/kernel/fs/afs/afs.o I have the partition as shown in the docs: plmcvs bin # mount [...] /dev/hda8 on /vicepa type ext3 (rw) plmcvs bin # cat /etc/fstab # /etc/fstab: static file system information. [...] /dev/hda8 /vicepa ext3 defaults 0 2 [...] I loaded the module without problems plmcvs root # modprobe -vvvvv afs /sbin/insmod /lib/modules/2.4.23/kernel/fs/afs/afs.o Using /lib/modules/2.4.23/kernel/fs/afs/afs.o Symbol version prefix '' Warning: loading /lib/modules/2.4.23/kernel/fs/afs/afs.o will taint the kernel: no license See http://www.tux.org/lkml/#export-tainted for information about tainted modules Module afs loaded, with warnings Ok, kernel tainted but I don't care. The next step is impossible: plmcvs bin # ./bosserver -noauth & [1] 15377 [1]+ Done ./bosserver -noauth (mmm... Done???) plmcvs bin # ps auxw|grep bos root 15379 0.1 0.2 3804 2792 ? S 11:02 0:00 ./bosserver -noauth root 15444 0.0 0.0 1500 460 pts/1 R 11:02 0:00 grep bos (ok...) plmcvs bin # ls -l /usr/vice/etc lrwxrwxrwx 1 root root 8 Mar 15 18:03 /usr/vice/etc -> /etc/afs/ (ok...) plmcvs bin # ./bos setcellname afs.myedu.edu mycell.edu -noauth bos: failed to set cell (communications failure (-1)) (What????????????????????????????????) plmcvs bin # lsmod Module Size Used by Tainted: P afs 435192 0 (unused) sg 28268 0 (autoclean) (unused) sr_mod 14424 0 (autoclean) (unused) sd_mod 11180 0 (autoclean) (unused) scsi_mod 87444 3 (autoclean) [sg sr_mod sd_mod] ide-cd 32480 0 (autoclean) cdrom 29376 0 (autoclean) [sr_mod ide-cd] floppy 52028 0 (autoclean) plmcvs bin # As you can see, I have afs module loaded... I don't know, maybe I did not follow some steps... Can you help me? -- Sensei f u cn rd ths u r usng unx From hendrik.hoeth@cern.ch Tue Mar 16 10:24:54 2004 From: hendrik.hoeth@cern.ch (Hendrik Hoeth) Date: Tue, 16 Mar 2004 11:24:54 +0100 Subject: [OpenAFS] Bos: communication failed??? In-Reply-To: <4056D314.9070809@tin.it> References: <4056D314.9070809@tin.it> Message-ID: <20040316102447.GA9982@mail.physik.uni-wuppertal.de> Thus spake Sensei (senseiwa@tin.it): > I emerged (gentoo linux, kernel 2.4.23) openafs, and so I found the > modules into /etc/afs/modload Which openafs version do you have? Gentoo updated to 1.2.11 rather late, so if you still have 1.2.10 try to update. > plmcvs bin # ./bosserver -noauth & > [1] 15377 > [1]+ Done ./bosserver -noauth > > (mmm... Done???) That's fine ... > As you can see, I have afs module loaded... I don't know, maybe I did > not follow some steps... Can you help me? You don't need the kernel module at this point. It's just for the client, the server lives in userland. -- for (Int_t j = 0; j < 100; j++){ // ROOT Users Guide 3.10, p. 243 if (j < 100){ smallHisto->Fill(fTracks_fPx[j]); } } From senseiwa@tin.it Tue Mar 16 10:41:51 2004 From: senseiwa@tin.it (Sensei) Date: Tue, 16 Mar 2004 11:41:51 +0100 Subject: [OpenAFS] Bos: communication failed??? In-Reply-To: <20040316102447.GA9982@mail.physik.uni-wuppertal.de> References: <4056D314.9070809@tin.it> <20040316102447.GA9982@mail.physik.uni-wuppertal.de> Message-ID: <4056D9EF.8020905@tin.it> Hendrik Hoeth wrote: > Which openafs version do you have? Gentoo updated to 1.2.11 rather late, > so if you still have 1.2.10 try to update. I use openafs 1.2.11 > You don't need the kernel module at this point. It's just for the > client, the server lives in userland. Ok, I removed the kernel module, but it's still the same: plmcvs root # cd /usr/afs/bin/ plmcvs bin # ./bosserver -noauth & [1] 8880 [1]+ Done ./bosserver -noauth plmcvs bin # ./bos setcellname host.name.edu cell.name.edu bos: a pioctl failed (getting tickets) bos: running unauthenticated bos: failed to set cell (communications failure (-1)) (I forgot -noauth... anyway it's ok) -- Sensei f u cn rd ths u r usng unx From senseiwa@tin.it Tue Mar 16 10:49:49 2004 From: senseiwa@tin.it (Sensei) Date: Tue, 16 Mar 2004 11:49:49 +0100 Subject: [OpenAFS] Bos: communication failed??? In-Reply-To: <4056D9EF.8020905@tin.it> References: <4056D314.9070809@tin.it> <20040316102447.GA9982@mail.physik.uni-wuppertal.de> <4056D9EF.8020905@tin.it> Message-ID: <4056DBCD.70808@tin.it> After some seconds, I get: plmcvs bin # bind: Address already in use rxi_GetUDPSocket: bind failed -- Sensei f u cn rd ths u r usng unx From matt@njit.edu Tue Mar 16 11:37:32 2004 From: matt@njit.edu (Matthew E Hoskins - SAGE AFS) Date: Tue, 16 Mar 2004 06:37:32 -0500 Subject: [OpenAFS] openssh-3.7.1, pam and no token after login In-Reply-To: <20040315161851.GC3621@hanuman.astro.su.se> References: <20031216024537.GB7479@mail.physik.uni-wuppertal.de> <2667060000.1071681540@mariner.pc.cs.cmu.edu> <4055D34D.7070103@njit.edu> <20040315161851.GC3621@hanuman.astro.su.se> Message-ID: <4056E6FC.6060302@njit.edu> These solutions seem krb5 centric, we use kaserver on all our cells. Sergio Gelato wrote: >* Matthew Hoskins [2004-03-15 11:01:17 -0500]: > > >>This thread seems to have died... Did anyone ever find a combination of >>patches/config options that allow a modern version of openssh to get a >>pag+token? >> >> > >Yes. OpenSSH 3.8p1 with Heimdal 0.6 (or newer). UsePAM=no, >KerberosAuthentication=yes, KerberosGetAFSToken=yes, and if you apply my > http://www.astro.su.se/~gelato/patches/openssh-3.8p1-1.diff >it will even work with GSSAPI-forwarded TGTs. > >I'm looking at making a trimmed-down version of krbafs / libkafs with >just the k_hasafs() and k_setpag() calls; this could be contributed to >OpenSSH, with a helper program being forked to get the actual token >(as advocated by Douglas Engert, who posted some relevant patches to >openssh-unix-dev@mindrot.org). I need this for Linux (Debian woody), >where (obsolete) Heimdal vs. MIT Kerberos issues are getting in my way. >(Most of these should be solved in Debian sarge, but I can't deploy >that in production yet.) > > > >>I have tried just about every combination of UsePAM, >>UsePrivilegeSeparation, 3.7p and 3.8p versions. My platform is solaris 8. >> >> > >I'm running happily on Solaris 8 (SPARC) with the above Heimdal-based >setup, and UsePrivilegeSeparation=yes, GSSAPIAuthentication=yes. >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > > From senseiwa@tin.it Tue Mar 16 12:18:21 2004 From: senseiwa@tin.it (Sensei) Date: Tue, 16 Mar 2004 13:18:21 +0100 Subject: [OpenAFS] Bos: communication failed??? In-Reply-To: <4056DBCD.70808@tin.it> References: <4056D314.9070809@tin.it> <20040316102447.GA9982@mail.physik.uni-wuppertal.de> <4056D9EF.8020905@tin.it> <4056DBCD.70808@tin.it> Message-ID: <4056F08D.2010601@tin.it> Sensei wrote: > After some seconds, I get: > > plmcvs bin # bind: Address already in use > rxi_GetUDPSocket: bind failed DNS failure... sorry :) But I'll ask another question... -- Sensei f u cn rd ths u r usng unx From senseiwa@tin.it Tue Mar 16 12:24:54 2004 From: senseiwa@tin.it (Sensei) Date: Tue, 16 Mar 2004 13:24:54 +0100 Subject: [OpenAFS] VOL create failed Message-ID: <4056F216.5000602@tin.it> I'm following a debian documentation to create the cell (http://www.debianplanet.org/node.php?id=816). And I use gentoo which is slightly different (more adeherent to the openafs locations). Moreover, I'm trying to have a kerberos 5 authentication, so no kaserver & co. I follow every step but at the # vos create blah blah blah -noauth I get an error: it cannot fetch the partitions from the server, possible communication failure. I noticed that the /usr/lib/openafs/salvager is not running, even if the bos create command showed no errors... I'm trying but I cannot figure out what's happening... -- Sensei f u cn rd ths u r usng unx From Laatsch@rrz.Uni-Koeln.DE Tue Mar 16 12:29:51 2004 From: Laatsch@rrz.Uni-Koeln.DE (Rainer Laatsch) Date: Tue, 16 Mar 2004 13:29:51 +0100 (MET) Subject: [OpenAFS] openssh-3.8p1+PAM+solaris8+token OK Message-ID: <200403161229.NAA01450@campfire.rrz.Uni-Koeln.DE> The following setup is working as First-Aid on Solaris-8 for PAM witout KRB5. Its not the final solution .... Method: grab the PAM password via PAM setenv to session (sshd child); start a Klog with password from environment; then start user (wont see nothing). Start sshd under pagsh, else (if Klog fails silently) a user could get a token of root. Root users: use AFS klog with param '-setpag' to be cautious. Have pam_afs as last entry in respective pam.conf sshd entries to grab the right password. PrivSep yes/no wont matter. Best regards, Rainer Laatsch@Uni-Koeln.DE My simple Klog script: #!/bin/ksh export PATH=/bin:/usr/bin:/usr/sbin:/sbin:/usr/ucb # SunOS umask 077 # for LOGFILE MYID=`expr "\`id\`" : 'uid=\([0-9]*\)'` ## thats ok LOG=/tmp/Klog-$MYID.log ; print >>$LOG ; date >>$LOG print "Klog :$USER:$LOGNAME:$UID: $*" >>$LOG # $USER,$LOGNAME,$UID: none set yet [ $MYID -eq 0 ] && exit ## no good for root # grab environment: print $AUTHPW | /usr/afsws/bin/klog $* ## -pipe -setpag #knows its user # !!!!!!! /bin/id -a >>$LOG ; /usr/afsws/bin/tokens >>$LOG # ------------------ /etc/pam.conf additions: have pam_afs always last ! sshd auth requisite pam_authtok_get.so.1 debug sshd auth optional pam_dhkeys.so.1 debug sshd auth optional pam_unix_auth.so.1 debug sshd auth optional pam_afs.so.1 try_first_pass ignore_root debug sshd account optional pam_unix_account.so.1 sshd account optional pam_afs.so.1 ignore_root debug sshd session optional pam_unix_session.so.1 sshd session optional pam_afs.so.1 try_first_pass ignore_root debug # ------------------ /etc/ssh/sshd_config override/add Port 522 LogLevel DEBUG X11Forwarding yes PrintMotd no UsePrivilegeSeparation no # Wont matter. If no sshd user in passwd ChallengeResponseAuthentication yes # PAM needs this UsePAM yes KbdInteractiveAuthentication yes # else PAM doesnt work # ------------------ Patches: *** openssh-3.8p1.ORIG/auth-pam.c Tue Feb 17 13:20:08 2004 --- openssh-3.8p1/auth-pam.c Tue Mar 16 10:46:00 2004 *************** *** 267,272 **** --- 267,274 ---- if (buffer_get_char(&buffer) != PAM_AUTHTOK) goto fail; reply[i].resp = buffer_get_string(&buffer, NULL); + do_pam_putenv("AUTHPW\0",reply[i].resp); /*RL*/ + break; case PAM_PROMPT_ECHO_ON: buffer_put_cstring(&buffer, *** openssh-3.8p1.ORIG/session.c Mon Feb 23 14:01:27 2004 --- openssh-3.8p1/session.c Tue Mar 16 10:31:29 2004 *************** *** 951,956 **** --- 951,985 ---- } *var_val++ = '\0'; + if ( 0 == strcmp("AUTHPW",var_name) ) /* match */ + { + int pklog; int lenkenv; int status; + char klogenv [256]; + char * klogcmd="/afs/rrz.uni-koeln.de/vol/openssh/@sys/current/sbin/Klog"; + char* enve[2]; + strcpy(klogenv,"AUTHPW="); lenkenv=strlen(klogenv); + strcpy(klogenv+lenkenv,var_val); lenkenv=strlen(klogenv); + klogenv[lenkenv]='\0'; + enve[0]=klogenv; enve[1]=(char * ) NULL; + pklog=fork() ; + if (pklog >=0) /* forked with success else no-op */ + { + if (pklog == 0) + { /* child . We are already running as USER but Klog does not know? */ + /* ??? if( k_haspag () ) { k_setpag() ; } ??? */ + execle(klogcmd, "Klog" ,"-setpag","-pipe", (char*) NULL, enve); + exit(0); /* not reached */ + } + else + { /* parent */ + while (waitpid(pklog, &status, 0) < 0) if (errno != EINTR) break; + } /* parent */ + } /* fork*/ + /* DONT debug3("AUTHPW=%s",var_val); */ + xfree(var_name); + continue; /* never give to user */ + } /* AUTHPW */ + debug3("Copy environment: %s=%s", var_name, var_val); child_set_env(env, envsize, var_name, var_val); *************** *** 1540,1545 **** --- 1569,1590 ---- argv[0] = (char *) shell0; argv[1] = "-c"; argv[2] = (char *) command; + + #ifndef SCPDIR + /* Help root to find scp. Laatsch@rrz.uni-koeln.de */ + #define SCPDIR "/vol/openssh/bin/" + /* 0123456789+1234567 17++ */ + #endif + #ifdef SCPDIR + if ( (strlen(command) >=4) && (strncmp("scp ",command,4) == 0) ) + { char * buf; int comlen=strlen(command); int pathlen=strlen( SCPDIR ); + buf=xmalloc(pathlen+comlen+1); + strcpy(buf, SCPDIR ); + strcpy( (char *) &(buf[pathlen]), command); buf[pathlen+comlen]=NULL; + argv[2] = buf; + } + #endif + argv[3] = NULL; execve(shell, argv, env); perror(shell); From kwc@citi.umich.edu Tue Mar 16 14:46:36 2004 From: kwc@citi.umich.edu (Kevin Coffman) Date: Tue, 16 Mar 2004 09:46:36 -0500 Subject: [OpenAFS] VOL create failed In-Reply-To: <4056F216.5000602@tin.it> Message-ID: <002401c40b65$7bab68d0$b285d38d@citi.umich.edu> You shouldn't see the salvager running, you should see the fileserver = and volserver running. What does "bos status -long" show? -----Original Message----- From: openafs-info-admin@openafs.org = [mailto:openafs-info-admin@openafs.org] On Behalf Of Sensei Sent: Tuesday, March 16, 2004 7:25 AM To: openafs-info@openafs.org Subject: [OpenAFS] VOL create failed I'm following a debian documentation to create the cell=20 (http://www.debianplanet.org/node.php?id=3D816). And I use gentoo which = is=20 slightly different (more adeherent to the openafs locations). Moreover, I'm trying to have a kerberos 5 authentication, so no kaserver = & co. I follow every step but at the # vos create blah blah blah -noauth I get an error: it cannot fetch the partitions from the server, possible = communication failure. I noticed that the /usr/lib/openafs/salvager is not running, even if the = bos create command showed no errors... I'm trying but I cannot figure out what's happening... --=20 Sensei f u cn rd ths u r usng unx _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From senseiwa@tin.it Tue Mar 16 15:02:46 2004 From: senseiwa@tin.it (Sensei) Date: Tue, 16 Mar 2004 16:02:46 +0100 Subject: [OpenAFS] VOL create failed In-Reply-To: <002401c40b65$7bab68d0$b285d38d@citi.umich.edu> References: <002401c40b65$7bab68d0$b285d38d@citi.umich.edu> Message-ID: <40571716.6050406@tin.it> Kevin Coffman wrote: > You shouldn't see the salvager running, you should see the fileserver and > volserver running. What does "bos status -long" show? This is the output. You'll see salvager running just because I tried to create a volume with the process running. plmcvs bin # ./bos status plmcvs -long bos: a pioctl failed (getting tickets) bos: running unauthenticated Instance ptserver, (type is simple) currently running normally. Process last started at Tue Mar 16 14:33:12 2004 (4 proc starts) Last exit at Tue Mar 16 14:33:12 2004 Command 1 is '/usr/afs/bin/ptserver' Instance fs, (type is fs) currently running normally. Auxiliary status is: file server running. Process last started at Tue Mar 16 16:02:31 2004 (65 proc starts) Last exit at Tue Mar 16 16:02:31 2004 Last error exit at Tue Mar 16 16:02:31 2004, by vol, by exiting with code 1 Command 1 is '/usr/afs/bin/fileserver' Command 2 is '/usr/afs/bin/volserver' Command 3 is '/usr/afs/bin/salvager' Instance vlserver, (type is simple) currently running normally. Process last started at Tue Mar 16 14:33:12 2004 (3 proc starts) Last exit at Tue Mar 16 14:33:12 2004 Command 1 is '/usr/afs/bin/vlserver' -- Sensei f u cn rd ths u r usng unx From Bernd.Laumann@inform.fh-hannover.de Tue Mar 16 15:14:39 2004 From: Bernd.Laumann@inform.fh-hannover.de (Bernd Laumann) Date: Tue, 16 Mar 2004 16:14:39 +0100 Subject: [OpenAFS] Problem with the cachemanager Message-ID: Hi, I am installing OpenAFS on Suse Enterprise Server 8 amd I have the following problem: 1. I set the cachesize in /usr/vice/etc/cacheinfo to 50000 (or another term) (cache at /usr/vice) , the correct start of the asfd is not possible. If I remove this settings, klog and other are out of order. 2. The other case, I want to set the cachememory to the memory, I don't find the syntax of the input. Who can help me? Perhaps someone can send me the file to set the cache into the memory. Greetings from Hannover Bernd -- Bernd Laumann Dipl. Phys. Fachbereich Informatik http://www.inform.fh-hannover.de Fachhochschule Hannover http://www.fh-hannover.de Ricklinger Stadtweg 120 30459 Hannover, Germany mailto:bernd.laumann@inform.fh-hannover.de Tel .: +49 (0)511-9296-1826 Fax .: +49 (0)511-9296-1810 Mobil: +49 (0)170-4767862 From kwc@citi.umich.edu Tue Mar 16 15:23:10 2004 From: kwc@citi.umich.edu (Kevin Coffman) Date: Tue, 16 Mar 2004 10:23:10 -0500 Subject: [OpenAFS] VOL create failed In-Reply-To: <40571716.6050406@tin.it> Message-ID: <003001c40b6a$971dad80$b285d38d@citi.umich.edu> So it looks like your volume server (volserver) is dieing. Hopefully = there is a hint in its log? -----Original Message----- From: openafs-info-admin@openafs.org = [mailto:openafs-info-admin@openafs.org] On Behalf Of Sensei Sent: Tuesday, March 16, 2004 10:03 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] VOL create failed Instance fs, (type is fs) currently running normally. Auxiliary status is: file server running. Process last started at Tue Mar 16 16:02:31 2004 (65 proc starts) Last exit at Tue Mar 16 16:02:31 2004 Last error exit at Tue Mar 16 16:02:31 2004, by vol, by exiting=20 with code 1 Command 1 is '/usr/afs/bin/fileserver' Command 2 is '/usr/afs/bin/volserver' Command 3 is '/usr/afs/bin/salvager' From boyland@solomons.cs.uwm.edu Tue Mar 16 15:30:46 2004 From: boyland@solomons.cs.uwm.edu (John Tang Boyland) Date: Tue, 16 Mar 2004 09:30:46 -0600 Subject: [OpenAFS] Solaris x86 also crashes because of item 1434 Message-ID: <7200.1079451046@pabst.cs.uwm.edu> Last summer AFS bug #1434 was apparently fixed for Solaris 8 on SPARC, but apparently not fixed for Solaris 8 on Intel. I was hoping the latest openafs would fix this, but it appears that the kernel module for 1.2.11 is the same as the one for 1.2.10. I finally patched my system and now starting afs crashes the kernel. (I tried to set this as a comment to ticket #1434, but (1) I don't know who would get the comment, and (2) guest is not allowed to post comments and (3) rt.central.org doesn't mention how to create a non-guest account.) John From senseiwa@tin.it Tue Mar 16 15:34:26 2004 From: senseiwa@tin.it (Sensei) Date: Tue, 16 Mar 2004 16:34:26 +0100 Subject: [OpenAFS] VOL create failed In-Reply-To: <003001c40b6a$971dad80$b285d38d@citi.umich.edu> References: <003001c40b6a$971dad80$b285d38d@citi.umich.edu> Message-ID: <40571E82.8080001@tin.it> Kevin Coffman wrote: > So it looks like your volume server (volserver) is dieing. Hopefully there > is a hint in its log? This is the output of BosLog and FileLog. I cleared all logs and then re-run ``vos create .....'': plmcvs logs # cat BosLog Tue Mar 16 16:33:27 2004: fs:vol exited with code 1 plmcvs logs # cat FileLog Tue Mar 16 16:33:21 2004 Couldn't get CPS for AnyUser, will try again in 30 seconds; code=-1. Tue Mar 16 16:34:26 2004 Couldn't get CPS for AnyUser, will try again in 30 seconds; code=-1. plmcvs logs # -- Sensei f u cn rd ths u r usng unx From kwc@citi.umich.edu Tue Mar 16 15:58:17 2004 From: kwc@citi.umich.edu (Kevin Coffman) Date: Tue, 16 Mar 2004 10:58:17 -0500 Subject: [OpenAFS] VOL create failed In-Reply-To: <40571E82.8080001@tin.it> Message-ID: <003101c40b6f$7f0f6fd0$b285d38d@citi.umich.edu> The "Couldn't get CPS" message means that the fileserver cannot = communicate with the ptserver. Until that is fixed, the volume server cannot communicate with the fileserver. Have you restarted everything since = fixing the /etc/hosts problem? -----Original Message----- From: openafs-info-admin@openafs.org = [mailto:openafs-info-admin@openafs.org] On Behalf Of Sensei Sent: Tuesday, March 16, 2004 10:34 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] VOL create failed Kevin Coffman wrote: > So it looks like your volume server (volserver) is dieing. Hopefully there > is a hint in its log? This is the output of BosLog and FileLog. I cleared all logs and then=20 re-run ``vos create .....'': plmcvs logs # cat BosLog Tue Mar 16 16:33:27 2004: fs:vol exited with code 1 plmcvs logs # cat FileLog Tue Mar 16 16:33:21 2004 Couldn't get CPS for AnyUser, will try again in = 30 seconds; code=3D-1. Tue Mar 16 16:34:26 2004 Couldn't get CPS for AnyUser, will try again in = 30 seconds; code=3D-1. plmcvs logs # --=20 Sensei f u cn rd ths u r usng unx _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From shadow@dementia.org Tue Mar 16 18:56:31 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Tue, 16 Mar 2004 13:56:31 -0500 (EST) Subject: [OpenAFS] Solaris x86 also crashes because of item 1434 In-Reply-To: <7200.1079451046@pabst.cs.uwm.edu> References: <7200.1079451046@pabst.cs.uwm.edu> Message-ID: On Tue, 16 Mar 2004, John Tang Boyland wrote: > Last summer AFS bug #1434 was apparently fixed for Solaris 8 on SPARC, > but apparently not fixed for Solaris 8 on Intel. I was hoping > the latest openafs would fix this, but it appears that the > kernel module for 1.2.11 is the same as the one for 1.2.10. > I finally patched my system and now starting afs crashes the kernel. that's not shocking. there's a Changelog and if you notice, none of the changes should be touching the kernel module. without looking, i'll guess this was the "kernel jumbos after -20" problem. > (I tried to set this as a comment to ticket #1434, but (1) I don't > know who would get the comment, and (2) guest is not allowed to > post comments and (3) rt.central.org doesn't mention how to create > a non-guest account.) From boyland@solomons.cs.uwm.edu Tue Mar 16 19:22:45 2004 From: boyland@solomons.cs.uwm.edu (John Tang Boyland) Date: Tue, 16 Mar 2004 13:22:45 -0600 Subject: [OpenAFS] Solaris x86 also crashes because of item 1434 In-Reply-To: Your message of "Tue, 16 Mar 2004 18:51:14 +0100." Message-ID: <7373.1079464965@pabst.cs.uwm.edu> ] * John Tang Boyland [2004-03-16 09:30:46 -0600]: ] > Last summer AFS bug #1434 was apparently fixed for Solaris 8 on SPARC, ] > but apparently not fixed for Solaris 8 on Intel. I was completely wrong here. It turns out I had installed the afs kernel module as /kernel/afs, and the old kernel was still in /kernel/fs/afs. Sorry for bothering people. Thanks to Sergio Gelato. John From cmillet@qualcomm.com Tue Mar 16 20:38:23 2004 From: cmillet@qualcomm.com (Millet, Christopher) Date: Tue, 16 Mar 2004 12:38:23 -0800 Subject: [OpenAFS] "ws" in scout utility Message-ID: <7962AE4495DBF74BB35C679D7CDE91933A1FF7@NAEX02.na.qualcomm.com> The definition of this is "displays the number of client machines that have communicated with the file server process within the last 15 minutes. What does this really mean? Is that the number of clients being served data from that file server or something else? The reason I ask is we have a file server that is out in a really remote site that has some volumes replicated to it. There is only about 100 clients at that site, but scout is showing > 600 workstations to it and > 2k connections. This seems abnormally high and I'm worried that clients locally somehow have this remote file server with a low server pref and might be going out there to get data that has been replicated there when it can and should be going to local servers that have the same data replicated here. -Chris From Renata Maria Dart Tue Mar 16 23:32:31 2004 From: Renata Maria Dart (Renata Maria Dart) Date: Tue, 16 Mar 2004 15:32:31 -0800 (PST) Subject: [OpenAFS] Solaris unlink removes AFS mount points Message-ID: <0HUP003I5027XM@mailbox.slac.stanford.edu> We just discovered that the unlink system call in Solaris will remove AFS mount points (i.e., unmount the AFS volume). This can be demonstrated with the unlink command. $ uname -a SunOS shire03 5.8 Generic_108528-27 sun4u sparc SUNW,Sun-Fire $ pwd /afs/slac.stanford.edu/u/sf/ljm/tmp/unlink_bug $ fs mkmount test_mount rzc.test.test $ fs lsmount test_mount 'test_mount' is a mount point for volume '#rzc.test.test' $ unlink test_mount $ fs lsmount test_mount fs: File 'test_mount' doesn't exist Exit 1 $ ls -ld test_mount test_mount: No such file or directory Exit 2 Note that the above example was executed by an ordinary user account without root privileges. We are running OpenAFS 1.2.10 on this particular solaris 8 system. It should be noted that Solaris supports the POSIX option that permits unlink to remove directories under some circumstances, as described in the unlink(2) man page: The path argument must not name a directory unless the pro- cess has appropriate privileges and the implementation sup- ports using unlink() on directories. For an ordinary filesystem, the root account has the "appropriate privileges" to unlink directories. However, root should have no special privileges in AFS filesystems. So we don't think that AFS should permit the unlink system call to remove AFS mount points either for root or non-root users. -Renata Renata Dart | renata@SLAC.Stanford.edu Stanford Linear Accelerator Center | 2575 Sand Hill Road, MS 97 | (650) 926-2848 (office) Stanford, California 94025 | (650) 926-3329 (fax) From allbery@ece.cmu.edu Tue Mar 16 23:39:23 2004 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue, 16 Mar 2004 18:39:23 -0500 Subject: [OpenAFS] Solaris unlink removes AFS mount points In-Reply-To: <0HUP003I5027XM@mailbox.slac.stanford.edu> References: <0HUP003I5027XM@mailbox.slac.stanford.edu> Message-ID: <1079480362.20641.4.camel@rushlight.kf8nh.com> On Tue, 2004-03-16 at 18:32, Renata Maria Dart wrote: > For an ordinary filesystem, the root account has the "appropriate > privileges" to unlink directories. However, root should have no > special privileges in AFS filesystems. So we don't think that AFS > should permit the unlink system call to remove AFS mount points either > for root or non-root users. I would argue there's no reason to worry about it. Local directories require root permission because exercising unlink(2) directly on one will damage the filesystem unless done properly (i.e. insure directory contains only "." and "..", unlink "." and ".." entries, unlink directory). As an AFS mountpoint is really just a symlink, one cannot cause volume corruption by unlinking it directly. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From Jeffrey.B.Woodward@Dartmouth.EDU Wed Mar 17 03:30:46 2004 From: Jeffrey.B.Woodward@Dartmouth.EDU (Jeff Woodward) Date: Tue, 16 Mar 2004 22:30:46 -0500 (EST) Subject: [OpenAFS] OpenAFS Solaris 10 port Message-ID: <20040316193040.N30675@phortse.Dartmouth.EDU> For anyone interested in a port of OpenAFS to Solaris 10, I would be happy to share my experiences, code base, and binaries. Presently, I have a source tree based on the OpenAFS-1.2.10 distribution that compiles both the 32 and 64 bit kernel modules using the Sun compiler under Sparc Solaris10. I have done preliminary testing of the client using the 64 bit kernel module which seems to be working well (see open issues below); I have tested most of the major client utilities. I have not yet tested the AFS server functionality on this platform (nor have I patched for the known "date roll-over bug" that exists in the 1.2.10 server code base). For those who care, more details are included below. If early access to this work is desired, please send me email directly. If the requests are overwhelming, I will make them AFS and web accessible and repost this list; otherwise, I will be posting "proper" changes against the CVS tree to the devel list for inclusion in some future release of OpenAFS. -Jeff Woodward Project Manager - Systems and Development The fMRI Data Center Dartmouth College Overview of Current Work ------------------------ (*) Assigned SYS_NAME_ID_sun4x_510 to be 941 in src/config/afs_sysnames.h (*) Created param.sun4x_510.h and param.sun4x_510_usr.h files in src/config (*) Numerous changes to src/libafs/MakefileProto.SOLARIS.in to add sun4x_510 system type. (*) Add includes for cred_impl.h to src/afs/sysincludes.h -- caveat this may not be the right thing to do; as it appears that cred_impl isn't suppose to be publicly exposed; however, it seems to be compiling and working for the moment but my guess is that it is subject to break in future Solaris releases. (*) Hack to src/venus/Makefile.in to pickup sysname sun4x_510 in order to get the correct libraries for linking kdump. (*) Method for traversing network interfaces has changed within the Solaris "ip" kernel module -- resulting in changes to src/afs/SOLARIS/osi_vfsops.c, src/afs/afs_server.c, and rx/SOLARIS/rx_knet.c (*) tv_usec and tv_sec changed(?) effecting struct timeval -- resulting in changes to src/afs/afs_osi.h (I got away with typedef'ing osi_timeval_t as a plain old struct timeval rather than using the one included in the afs source with afs_int32 tv_sec and tv_usec typed members -- no claim that this was the right choice). (*) Solaris 10 seems to have made somewhat extensive changes to the VFS interface. I am flying blind here as I don't have source code for Solaris 10, so I based my changes on the comments and changes in the sys/vfs.h and sys/vnode.h header files. These changes resulted in modifications to src/afs/SOLARIS/osi_vfsops.c and src/afs/SOLARIS/osi_vnodeops.c as well as src/afs/VNOPS/afs_vnop_read.c and src/afs/VNOPS/afs_vnop_write.c. A little bit of clean up is still needed here. Perhaps the most nebulous of the changes to VFS interface is the addition of the 'caller_context_t*' parameter to the vop_read and vop_write vnodeops which subsequently effects the VOP_READ and VOP_WRITE macros. I am not an avid kernel hacker, so I don't know if this construct exists in other operating systems, nor do I know what necessitated this change on Sun's part. Nonetheless, I updated the afs_vmread and afs_vmwrite function definitions accordingly but I didn't add any code to utilize the caller_context. Likewise, I pass a caller_context_t* parameter to VOP_READ and VOP_WRITE but I have no idea "why" other than it is now part of the API. For now it seems to be working (see also the open issues). (*) Solaris 10 seems to have made some minor (?) changes to the sockfs kernel interface. In particular, the sounbind() function is gone! This resulted in changes to src/rx/SOLARIS/rx_knet.c. See open issues below. Open Issues ----------- (*) libtermlib.a - Solaris 10 base no such library -- for now, it was copied from a Solaris 9 system, but work should be done to eliminate its dependency. (*) vfsck is not compiling (so I removed it from Makefile) -- I am not ready to test the server; in addition, I tend to configure servers with the NAMEI interface. In short, vfsck is a very low priority for me. (*) Since sounbind() is missing, the socket for RX on port 7001 remains "mostly" bound after afs is shutdown and /afs is dismounted. I have tried various strategies such as "shutting down" and "closing" the socket, but even with that, it remains "bound" (as can be see in the output of netstat -an). Attempting to restart afs without rebooting either: 1) causes RX to fail to start preventing afs from starting, 2) appearance of everything starting, but I/O errors accessing /afs, 3) panic'ing the system. This may not be a big deal to most people since it is only an issue if you attempt to stop afs and restart it without rebooting. Many people claim that that never works anyway...I see no reason for it to not work if I can get the RX port unbind'ed. I have an email into the Solaris 10 kernel team for direction. (*) I plan to email the Solaris 10 kernel team asking for more information regarding the caller_context_t* parameters in vop_read/vop_write. (*) proper conditional compilation of the changes noted above for the Solaris 510 platform - currently, my source tree is not backwards compatible with prior versions of Solaris... Everything else is stuff that I have explicitly not tested (some I may, others I may never test :-) (*) HAVE NOT TESTED THE AFS SERVER COMPONENT - on my list of TO DOs (*) PAM module - not yet tested. (*) 32 bit sparc kernel module is untested (I don't have any sparcs that I boot with a 32 bit kernel -- hint: I am not likely to ever test this). (*) x86 Solaris - have not attempted necessary changes for x86 arch. Code changes are *probably* good to go, but the changes to Makefiles, param files, and afs_sysname.h have not been attempted. Not sure that I have Solaris 10 for x86 installed [yet]... (*) nfs translator - not tested (I have never attempted to use the nfs translator in any version of OpenAFS for any platform -- hint: I am not likely to ever test this). (*) memory cache - not yet tested but will do soon. (*) dynamic roots - tested only briefly (seemed to work) (*) there are probably a dozen other switches/options that I don't normally use or would think to test. Next Steps ---------- (*) Check out latest development branch from CVS and integrate changes with "proper" conditional compilation to maintain backwards compatibility. (*) Integrate suggestions from the Solaris 10 kernel team (if any are received). (*) Test the AFS server component. (*) It would be nice if vfsck would at least compile; however, I am not eager to claim that it would work even if I got it to compile :-) Hopefully somebody "more qualified" than I will help out here... (*) Post patch files to the devel list for evaluation and [hopefully] adoption. From kubin@opf.slu.cz Wed Mar 17 10:39:25 2004 From: kubin@opf.slu.cz (Lukas Kubin) Date: Wed, 17 Mar 2004 11:39:25 +0100 Subject: [OpenAFS] AFS doesn't identify me after aklog Message-ID: <40582ADD.80705@opf.slu.cz> This is a cryptographically signed message in MIME format. --------------ms080105010200010708000801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I created principal imap/my.ser.ver.dc and according to the naming conventions in pts also a user imap.my.ser.ver.dc I can kinit this user and receive valid tickets. I also can perform aklog. However, I can't see my pts user id when listing "tokens" on Linux system. This it the result: Tokens held by the Cache Manager: Tokens for afs@opf.slu.cz [Expires Mar 17 21:36] --End of list-- Of course, I don't have the appropriate user's rights too -- ie I cannot access dirs with access rights set to user imap.my.ser.ver.dc What could cause this problem and how could I solve it? Thank you. lukas -- Lukas Kubin phone: +420596398275 email: kubin@opf.slu.cz Information centre The School of Business Administration in Karvina Silesian University in Opava Czech Republic http://www.opf.slu.cz --------------ms080105010200010708000801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCC AzIwggIaoAMCAQICAgDmMA0GCSqGSIb3DQEBBAUAMDIxCzAJBgNVBAYTAkNaMQ8wDQYDVQQK EwZDRVNORVQxEjAQBgNVBAMTCUNFU05FVCBDQTAeFw0wMzExMTkxNDM4NTdaFw0wNDExMTgx NDM4NTdaMEUxDzANBgNVBAoTBkNFU05FVDEcMBoGA1UEChMTU2lsZXNpYW4gVW5pdmVyc2l0 eTEUMBIGA1UEAxMLbHVrYXMga3ViaW4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL7l zAuBktAjhaVuPR0S2kwnO/xt1fp9D2GdLpxu2NcqUsuyEC00k3VHEijgFzcNt7+QviV1y5nq P3nmCqk+eNp20Z3qrYZKGh0YTho/qPESyjFZ4P2NmV7W+SewXZ0IEtxD/DaOMQo8kww1ho5y zaxVgSRItwefSBEMmFYdqrxpAgMBAAGjgcIwgb8wHQYDVR0OBBYEFNBqBwZMDvExebpgW4m8 MCWtsegvMB8GA1UdIwQYMBaAFPhWGtmaeJVttIiEVTUvqgbz1yBaMDUGA1UdHwQuMCwwKqAo oCaGJGh0dHA6Ly93d3cuY2VzbmV0LmN6L3BraS9jcmwvY2NhLmNybDAOBgNVHQ8BAf8EBAMC BPAwGwYDVR0RBBQwEoEQa3ViaW5Ab3BmLnNsdS5jejAZBgNVHSAEEjAQMA4GDCsGAQQBvnkB AgIBATANBgkqhkiG9w0BAQQFAAOCAQEAuI/sMxZZa78h5+Mzo3IhgSxrVMl5Hbm2YgLWLHAx QG1NxG0W9bkggMmRWrW8Xotr8VPA4IySqBiVwOlVMdZ5GNcUiSCrrFU6zfxAXD6dAJuEHGfb Vz/dQntptJ9Dz/URteoMleNZjn2gPaLELEax2gaF+2cvbpW521CFJrxxMc2LdScRDBCFapWO GNbxqSflLqbT8TsrbmS1V6zUicXf2eUurKA36/psbtFdG03vVaD3+V+RMgHr6X5k1NUfDfSI pmX7irFEn7tMrxq630NTJUrEm1w4ivK/+f+6+F0ozeaamYS/Gm7LUFSgA15ZDtGCKySWQp2V B+gwUKfc+8R+WjCCAzIwggIaoAMCAQICAgDmMA0GCSqGSIb3DQEBBAUAMDIxCzAJBgNVBAYT AkNaMQ8wDQYDVQQKEwZDRVNORVQxEjAQBgNVBAMTCUNFU05FVCBDQTAeFw0wMzExMTkxNDM4 NTdaFw0wNDExMTgxNDM4NTdaMEUxDzANBgNVBAoTBkNFU05FVDEcMBoGA1UEChMTU2lsZXNp YW4gVW5pdmVyc2l0eTEUMBIGA1UEAxMLbHVrYXMga3ViaW4wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAL7lzAuBktAjhaVuPR0S2kwnO/xt1fp9D2GdLpxu2NcqUsuyEC00k3VHEijg FzcNt7+QviV1y5nqP3nmCqk+eNp20Z3qrYZKGh0YTho/qPESyjFZ4P2NmV7W+SewXZ0IEtxD /DaOMQo8kww1ho5yzaxVgSRItwefSBEMmFYdqrxpAgMBAAGjgcIwgb8wHQYDVR0OBBYEFNBq BwZMDvExebpgW4m8MCWtsegvMB8GA1UdIwQYMBaAFPhWGtmaeJVttIiEVTUvqgbz1yBaMDUG A1UdHwQuMCwwKqAooCaGJGh0dHA6Ly93d3cuY2VzbmV0LmN6L3BraS9jcmwvY2NhLmNybDAO BgNVHQ8BAf8EBAMCBPAwGwYDVR0RBBQwEoEQa3ViaW5Ab3BmLnNsdS5jejAZBgNVHSAEEjAQ MA4GDCsGAQQBvnkBAgIBATANBgkqhkiG9w0BAQQFAAOCAQEAuI/sMxZZa78h5+Mzo3IhgSxr VMl5Hbm2YgLWLHAxQG1NxG0W9bkggMmRWrW8Xotr8VPA4IySqBiVwOlVMdZ5GNcUiSCrrFU6 zfxAXD6dAJuEHGfbVz/dQntptJ9Dz/URteoMleNZjn2gPaLELEax2gaF+2cvbpW521CFJrxx Mc2LdScRDBCFapWOGNbxqSflLqbT8TsrbmS1V6zUicXf2eUurKA36/psbtFdG03vVaD3+V+R MgHr6X5k1NUfDfSIpmX7irFEn7tMrxq630NTJUrEm1w4ivK/+f+6+F0ozeaamYS/Gm7LUFSg A15ZDtGCKySWQp2VB+gwUKfc+8R+WjGCAicwggIjAgEBMDgwMjELMAkGA1UEBhMCQ1oxDzAN BgNVBAoTBkNFU05FVDESMBAGA1UEAxMJQ0VTTkVUIENBAgIA5jAJBgUrDgMCGgUAoIIBRTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAzMTcxMDM5MjVa MCMGCSqGSIb3DQEJBDEWBBTRISogJFmIM5On//koxtv6WN10UzBHBgkrBgEEAYI3EAQxOjA4 MDIxCzAJBgNVBAYTAkNaMQ8wDQYDVQQKEwZDRVNORVQxEjAQBgNVBAMTCUNFU05FVCBDQQIC AOYwSQYLKoZIhvcNAQkQAgsxOqA4MDIxCzAJBgNVBAYTAkNaMQ8wDQYDVQQKEwZDRVNORVQx EjAQBgNVBAMTCUNFU05FVCBDQQICAOYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEgYCg76t2e7egaKEbHBRaeWj/7P5y3nlXbP9QgynledApzzOo9zas m3GfAyZU7elcfbB5azM9cuvOn+jaaBRVfF7QZD6zLXTSkLmOy4tFTbmvP/RuO6tD7ZvPvdRn WHnWGWjGSgjwXn6O5FfxiLXkHdQPSGAq6mZjcNpIMUrEDuV9KQAAAAAAAA== --------------ms080105010200010708000801-- From Renata Maria Dart Wed Mar 17 16:13:57 2004 From: Renata Maria Dart (Renata Maria Dart) Date: Wed, 17 Mar 2004 08:13:57 -0800 (PST) Subject: [OpenAFS] Solaris unlink removes AFS mount points Message-ID: <0HUQ00EBEAF93D@mailbox.slac.stanford.edu> Hi, although such a call can't cause volume corruption it can nevertheless cause a program to behave incorrectly. For example, consider a user program that relies on the documented behavior of the Solaris unlink system call to remove files but not directories. One can argue that this is not a very safe way to program; however, it is not a hypothetical example. We recently upgraded gnu tar (gtar) from 1.13 to 1.13.25 and encountered exactly this problem (which is the reason for this report). Here's the summary of what we found with the new version of gtar: > In Solaris a gtar extract operation which crosses an AFS mount > point will unmount the AFS volume and a new directory will be > created in its place unless gtar's -k (or --keep-old-files) flag > is specified. Here's the relevant piece of a truss of such a > gtar extract in Solaris (in this example, "rzc_test_test" is the > target directory for the extract and is an AFS mount point at the > beginning of the operation): > > ... > mkdir("rzc_test_test", 0755) Err#17 EEXIST > unlink("rzc_test_test") = 0 > mkdir("rzc_test_test", 0755) = 0 > write(1, " r z c _ t e s t _ t e s".., 19) = 19 > open64("rzc_test_test/junk", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4 > close(4) = 0 > ... > > It appears that gtar first attempts to create the > output directory and then, if that fails because the directory > exists, it tries to unlink it. In the case of Solaris, the unlink > succeeds, so gtar repeats the mkdir and then goes on to populate the > directory (in this case with a single zero-length file named "junk"). This change in behavior is causing a number of our users very serious problems. -Renata >Date: Tue, 16 Mar 2004 18:39:23 -0500 >From: "Brandon S. Allbery KF8NH" >Subject: Re: [OpenAFS] Solaris unlink removes AFS mount points >To: Renata Maria Dart >Cc: openafs-info@openafs.org >MIME-version: 1.0 >Content-transfer-encoding: 7bit >X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bache.ece.cmu.edu >X-Spam-Level: >X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 >X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 2004.3.16.94414 >X-Keywords: > >On Tue, 2004-03-16 at 18:32, Renata Maria Dart wrote: >> For an ordinary filesystem, the root account has the "appropriate >> privileges" to unlink directories. However, root should have no >> special privileges in AFS filesystems. So we don't think that AFS >> should permit the unlink system call to remove AFS mount points either >> for root or non-root users. > >I would argue there's no reason to worry about it. Local directories >require root permission because exercising unlink(2) directly on one >will damage the filesystem unless done properly (i.e. insure directory >contains only "." and "..", unlink "." and ".." entries, unlink >directory). As an AFS mountpoint is really just a symlink, one cannot >cause volume corruption by unlinking it directly. > >-- >brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com >system administrator [WAY too many hats] allbery@ece.cmu.edu >electrical and computer engineering, carnegie mellon univ. KF8NH > Renata Dart | renata@SLAC.Stanford.edu Stanford Linear Accelerator Center | 2575 Sand Hill Road, MS 97 | (650) 926-2848 (office) Stanford, California 94025 | (650) 926-3329 (fax) From rees@umich.edu Wed Mar 17 16:25:42 2004 From: rees@umich.edu (Jim Rees) Date: Wed, 17 Mar 2004 11:25:42 -0500 Subject: [OpenAFS] Solaris unlink removes AFS mount points In-Reply-To: Renata Maria Dart, Wed, 17 Mar 2004 08:13:57 PST Message-ID: <20040317162542.175EA20A10@citi.umich.edu> I'm no Solaris expert, but it seems to me the problem here is that the Solaris vfs doesn't check that remove is not being called on a directory. If this is the case, wouldn't it make sense to do this check in gafs_remove? From shadow@dementia.org Wed Mar 17 20:23:34 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 17 Mar 2004 15:23:34 -0500 (EST) Subject: [OpenAFS] Solaris unlink removes AFS mount points In-Reply-To: <0HUQ00EBEAF93D@mailbox.slac.stanford.edu> References: <0HUQ00EBEAF93D@mailbox.slac.stanford.edu> Message-ID: if it's really gafs_remove doing it, perhaps this is the right answer? (against the head, not 1.2.x, and i haven't tried it, i'm just guessing) it should be that afs_remove has no business removing a mount point on any platform and so this is safe. --- src/afs/VNOPS/afs_vnop_remove.c 15 Jul 2003 23:14:30 -0000 1.25 +++ src/afs/VNOPS/afs_vnop_remove.c 17 Mar 2004 20:21:41 -0000 @@ -279,6 +279,15 @@ #endif return code; } + + if (adp->mvstat == 1) { +#ifdef AFS_OSF_ENV + afs_PutVCache(adp); + afs_PutVCache(tvc); +#endif + return EISDIR; + } + if (strlen(aname) > AFSNAMEMAX) { afs_PutFakeStat(&fakestate); #ifdef AFS_OSF_ENV On Wed, 17 Mar 2004, Renata Maria Dart wrote: > Hi, although such a call can't cause volume corruption it can > nevertheless cause a program to behave incorrectly. For > example, consider a user program that relies on the documented > behavior of the Solaris unlink system call to remove files but > not directories. One can argue that this is not a very safe way > to program; however, it is not a hypothetical example. We > recently upgraded gnu tar (gtar) from 1.13 to 1.13.25 and > encountered exactly this problem (which is the reason for this > report). Here's the summary of what we found with the new > version of gtar: > > > In Solaris a gtar extract operation which crosses an AFS mount > > point will unmount the AFS volume and a new directory will be > > created in its place unless gtar's -k (or --keep-old-files) flag > > is specified. Here's the relevant piece of a truss of such a > > gtar extract in Solaris (in this example, "rzc_test_test" is the > > target directory for the extract and is an AFS mount point at the > > beginning of the operation): > > > > ... > > mkdir("rzc_test_test", 0755) Err#17 EEXIST > > unlink("rzc_test_test") = 0 > > mkdir("rzc_test_test", 0755) = 0 > > write(1, " r z c _ t e s t _ t e s".., 19) = 19 > > open64("rzc_test_test/junk", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4 > > close(4) = 0 > > ... > > > > It appears that gtar first attempts to create the > > output directory and then, if that fails because the directory > > exists, it tries to unlink it. In the case of Solaris, the unlink > > succeeds, so gtar repeats the mkdir and then goes on to populate the > > directory (in this case with a single zero-length file named "junk"). > > This change in behavior is causing a number of our users very > serious problems. > > -Renata > > >Date: Tue, 16 Mar 2004 18:39:23 -0500 > >From: "Brandon S. Allbery KF8NH" > >Subject: Re: [OpenAFS] Solaris unlink removes AFS mount points > >To: Renata Maria Dart > >Cc: openafs-info@openafs.org > >MIME-version: 1.0 > >Content-transfer-encoding: 7bit > >X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bache.ece.cmu.edu > >X-Spam-Level: > >X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham > version=2.63 > >X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: > 2004.3.16.94414 > >X-Keywords: > > > >On Tue, 2004-03-16 at 18:32, Renata Maria Dart wrote: > >> For an ordinary filesystem, the root account has the "appropriate > >> privileges" to unlink directories. However, root should have no > >> special privileges in AFS filesystems. So we don't think that AFS > >> should permit the unlink system call to remove AFS mount points either > >> for root or non-root users. > > > >I would argue there's no reason to worry about it. Local directories > >require root permission because exercising unlink(2) directly on one > >will damage the filesystem unless done properly (i.e. insure directory > >contains only "." and "..", unlink "." and ".." entries, unlink > >directory). As an AFS mountpoint is really just a symlink, one cannot > >cause volume corruption by unlinking it directly. > > > >-- > >brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com > >system administrator [WAY too many hats] allbery@ece.cmu.edu > >electrical and computer engineering, carnegie mellon univ. KF8NH > > > > Renata Dart | renata@SLAC.Stanford.edu > Stanford Linear Accelerator Center | > 2575 Sand Hill Road, MS 97 | (650) 926-2848 (office) > Stanford, California 94025 | (650) 926-3329 (fax) > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From danno@internet2.edu Wed Mar 17 21:11:16 2004 From: danno@internet2.edu (Dan Pritts) Date: Wed, 17 Mar 2004 16:11:16 -0500 Subject: [OpenAFS] AFS on win4lin kernel In-Reply-To: References: <50825.151.201.9.92.1078083772.squirrel@webmail.cs.pitt.edu> Message-ID: <20040317211116.GA14059@internet2.edu> sorry for the late reply - not reading list mail regularly lately but perhaps my feedback will help. The Win4lin folks dont' distribute a kernel-source RPM per se. they do give you an rpm that contains the appropraite patches, eg, ~@wrx% rpm -qlp Kernel-Win4Lin3-RedHat9.0_2.4.20.30-01.src.rpm Kernel-Win4Lin3-RedHat9.0_2.4.20.30.patch Kernel-Win4Lin3-RedHat9.0_2.4.20.30.spec mki-adapter.patch win4lin-fix-bootloader win4lin-fix-bootloader.pl What you probably need to do is a) get a redhat 9 kernel-source RPM b) get the appropriate source RPM from win4lin & install it c) build a kernel, making sure to include support for the two new options that win4lin provides d) get the appropriate afs-kernel-source rpm & build modules for your newly built kernel danno On Mon, Mar 08, 2004 at 05:56:26PM -0500, Derek Atkins wrote: > install openafs-kernel-source > > make sure you have a kernel-source tree for the win4lin kernel! > > -derek > > artward@cs.pitt.edu writes: > > > All: > > > > I had AFS running beautifully with the stock Red Hat 9 kernel. > > > > Then, like an idiot, I installed a win4lin patched kernel, 2.4.20-30.9 , > > and now I can't install AFS any more. Installing the old RPM's didn't > > work, and when I tried to build the source RPM > > "openafs-1.2.11-rh9.0.1.src.rpm", the build failed complaining about > > "krb." (Installing "openafs-krb5-1.2.11-rh9.0.1.i386.rpm" didn't change > > this) > > > > So, my question is: has anybody gotten AFS working on this win4lin patched > > kernel? Where should I go? What should I do? From danno@internet2.edu Wed Mar 17 21:13:41 2004 From: danno@internet2.edu (Dan Pritts) Date: Wed, 17 Mar 2004 16:13:41 -0500 Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040309010939.8EE1CB087@smtpauth.easystreet.com> References: <20040309010939.8EE1CB087@smtpauth.easystreet.com> Message-ID: <20040317211341.GB14059@internet2.edu> > > Bring a sleeping bag if you're booting a 250 GB system under ext2 > Only if it crashed. ...or if it's reached its maximal-mount-count and forces an fsck at mount time. Actually, I think this can happen with ext3 as well. TUNE2FS(8) TUNE2FS(8) NAME tune2fs - adjust tunable filesystem parameters on second extended filesystems [...] -c max-mount-counts Adjust the maximal mounts count between two filesystem checks. If max-mount-counts is 0 then the number of times the filesystem is mounted will be disregarded by e2fsck(8) and the kernel. danno -- dan pritts danno@internet2.edu systems administrator 734/352-4953 office internet2 734/834-7224 mobile From shadow@dementia.org Wed Mar 17 21:33:55 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 17 Mar 2004 16:33:55 -0500 (EST) Subject: [OpenAFS] Re: Problems with reiserfs when start OpenAFS 1.2.11-fc1 Segmentation fault with kernel 2.4.22-1.2174.nptl In-Reply-To: <20040317211341.GB14059@internet2.edu> References: <20040309010939.8EE1CB087@smtpauth.easystreet.com> <20040317211341.GB14059@internet2.edu> Message-ID: On Wed, 17 Mar 2004, Dan Pritts wrote: > > > Bring a sleeping bag if you're booting a 250 GB system under ext2 > > > Only if it crashed. > > ...or if it's reached its maximal-mount-count and forces an fsck at mount time. > Actually, I think this can happen with ext3 as well. sure. i had that happen on my home fileserver recently, which has 660gb in ext3 filesystems. yawn. From tcreedon@easystreet.com Thu Mar 18 00:29:04 2004 From: tcreedon@easystreet.com (ted creedon) Date: Wed, 17 Mar 2004 16:29:04 -0800 Subject: [OpenAFS] ICMP packets In-Reply-To: Message-ID: <20040318002904.89925B098@smtpauth.easystreet.com> Why are ICMP packets used for AFS? Normally a firewall would drop pings. Thanks. tedc From shadow@dementia.org Thu Mar 18 04:44:33 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 17 Mar 2004 23:44:33 -0500 (EST) Subject: [OpenAFS] ICMP packets In-Reply-To: <20040318002904.89925B098@smtpauth.easystreet.com> References: <20040318002904.89925B098@smtpauth.easystreet.com> Message-ID: On Wed, 17 Mar 2004, ted creedon wrote: > Why are ICMP packets used for AFS? They are? > Normally a firewall would drop pings. Only if you configure them to. From warlord@MIT.EDU Thu Mar 18 05:17:27 2004 From: warlord@MIT.EDU (Derek Atkins) Date: Thu, 18 Mar 2004 00:17:27 -0500 Subject: [OpenAFS] ICMP packets In-Reply-To: (Derrick J. Brashear's message of "Wed, 17 Mar 2004 23:44:33 -0500 (EST)") References: <20040318002904.89925B098@smtpauth.easystreet.com> Message-ID: Derrick J Brashear writes: >> Normally a firewall would drop pings. > > Only if you configure them to. And such a firewall is configured incorrectly. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From senseiwa@tin.it Thu Mar 18 11:53:38 2004 From: senseiwa@tin.it (Sensei) Date: Thu, 18 Mar 2004 12:53:38 +0100 Subject: [OpenAFS] VOS: Always problems!!! Message-ID: <40598DC2.4010400@tin.it> I'm building the cell... without success. I corrected the dns mismatch, deleted every configuration file and run these commmands. On kadmin: addprinc -randkey afs addprinc -randkey afs/host.name ktadd -k /etc/krb5.keytab afs ktadd -k /etc/krb5.keytab afs/host.name ktadd -e des-cbc-crc:afs3 -k /etc/krb5.keytab afs ktadd -e des-cbc-crc:afs3 -k /etc/krb5.keytab afs/host.name ??? OK ./bosserver -noauth & [1] 1360 [1]+ Done ./bosserver -noauth === OK ./bos listhosts host.name -noauth bos: failed to get cell name (do not know that information) === OK ./bos create -server host.name -instance ptserver -type simple -cmd /usr/afs/bin/ptserver -cell plm.cell === OK bos adduser servername admin -cell plm.cell -noauth === OK ./bos listhosts host.name -noauth Cell name is plm.cell Host 1 is host.name === OK ./bos listkeys servername -cell plm.cell -noauth All done. === OK ./pts createuser -name admin -cell plm.cell -noauth User admin has id 1 === OK ./pts adduser admin system:administrators -cell plm.cell -noauth === OK ./pts membership admin -cell plm.cell -noauth Groups admin (id: 1) is a member of: system:administrators === OK ./bos restart host.name -all -cell plm.cell -noauth === OK ./bos create -server host.name -instance fs -type fs -cmd /usr/afs/bin/fileserver -cmd /usr/afs/bin/volserver -cmd /usr/afs/bin/salvager -cell plm.cell -noauth === OK <<<<<<<< after a while: FSYNC_clientInit temporary failure (will retry): Connection refused File server has restarted at Thu Mar 18 12:31:36 2004 ??? OK ./bos status host.name fs -long -noauth Instance fs, (type is fs) currently running normally. Auxiliary status is: file server running. Process last started at Thu Mar 18 12:30:04 2004 (2 proc starts) Command 1 is '/usr/afs/bin/fileserver' Command 2 is '/usr/afs/bin/volserver' Command 3 is '/usr/afs/bin/salvager' === OK ./vos create -server host.name -partition /vicepa -name root.afs -cell plm.cell -noauth Could not get an Id for volume root.afs Possible communication failure Error in vos create command. Possible communication failure. What am I missing??????? What communications? I see with ps auxw bosserver, ptserver, fileserver (sooooo many instances) all sleeping. With nmap -sU host.name (run on host.name) I see these ports: 123/udp open ntp 7000/udp open afs3-fileserver 7002/udp open afs3-prserver 7005/udp open afs3-volserver 7007/udp open afs3-bos Why!?!? I need to build this cell and I don't know which communications fails! -- Sensei f u cn rd ths u r usng unx From reuter@rzg.mpg.de Thu Mar 18 13:15:50 2004 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Thu, 18 Mar 2004 14:15:50 +0100 Subject: [OpenAFS] VOS: Always problems!!! In-Reply-To: <40598DC2.4010400@tin.it> References: <40598DC2.4010400@tin.it> Message-ID: <4059A106.3000901@rzg.mpg.de> Looks like your vlserver isn't running (port 7003) Hartmut Sensei wrote: > I'm building the cell... without success. I corrected the dns mismatch, > deleted every configuration file and run these commmands. > > On kadmin: > > addprinc -randkey afs > addprinc -randkey afs/host.name > ktadd -k /etc/krb5.keytab afs > ktadd -k /etc/krb5.keytab afs/host.name > ktadd -e des-cbc-crc:afs3 -k /etc/krb5.keytab afs > ktadd -e des-cbc-crc:afs3 -k /etc/krb5.keytab afs/host.name > > ??? OK > > ./bosserver -noauth & > [1] 1360 > [1]+ Done ./bosserver -noauth > > === OK > > ./bos listhosts host.name -noauth > bos: failed to get cell name (do not know that information) > > === OK > > ./bos create -server host.name -instance ptserver -type simple -cmd > /usr/afs/bin/ptserver -cell plm.cell > > === OK > > bos adduser servername admin -cell plm.cell -noauth > > === OK > > ./bos listhosts host.name -noauth > Cell name is plm.cell > Host 1 is host.name > > === OK > > ./bos listkeys servername -cell plm.cell -noauth > All done. > > === OK > > ./pts createuser -name admin -cell plm.cell -noauth > User admin has id 1 > > === OK > > ./pts adduser admin system:administrators -cell plm.cell -noauth > > === OK > > ./pts membership admin -cell plm.cell -noauth > Groups admin (id: 1) is a member of: > system:administrators > > === OK > > ./bos restart host.name -all -cell plm.cell -noauth > > === OK > > ./bos create -server host.name -instance fs -type fs -cmd > /usr/afs/bin/fileserver -cmd /usr/afs/bin/volserver -cmd > /usr/afs/bin/salvager -cell plm.cell -noauth > > === OK > > <<<<<<<< after a while: > > FSYNC_clientInit temporary failure (will retry): Connection refused > File server has restarted at Thu Mar 18 12:31:36 2004 > > ??? OK > > ./bos status host.name fs -long -noauth > Instance fs, (type is fs) currently running normally. > Auxiliary status is: file server running. > Process last started at Thu Mar 18 12:30:04 2004 (2 proc starts) > Command 1 is '/usr/afs/bin/fileserver' > Command 2 is '/usr/afs/bin/volserver' > Command 3 is '/usr/afs/bin/salvager' > > === OK > > ./vos create -server host.name -partition /vicepa -name root.afs -cell > plm.cell -noauth > > Could not get an Id for volume root.afs > Possible communication failure > Error in vos create command. > Possible communication failure. > > > What am I missing??????? What communications? > > I see with ps auxw bosserver, ptserver, fileserver (sooooo many > instances) all sleeping. > > With nmap -sU host.name (run on host.name) I see these ports: > 123/udp open ntp > 7000/udp open afs3-fileserver > 7002/udp open afs3-prserver > 7005/udp open afs3-volserver > 7007/udp open afs3-bos > > Why!?!? I need to build this cell and I don't know which communications > fails! > -- ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 RZG (Rechenzentrum Garching) fax +49-89-3299-1301 Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From senseiwa@tin.it Thu Mar 18 14:19:07 2004 From: senseiwa@tin.it (Sensei) Date: Thu, 18 Mar 2004 15:19:07 +0100 Subject: [OpenAFS] VOS: Always problems!!! In-Reply-To: <4059A106.3000901@rzg.mpg.de> References: <40598DC2.4010400@tin.it> <4059A106.3000901@rzg.mpg.de> Message-ID: <4059AFDB.7090505@tin.it> Hartmut Reuter wrote: > Looks like your vlserver isn't running (port 7003) >> ./bos create -server host.name -instance fs -type fs -cmd >> /usr/afs/bin/fileserver -cmd /usr/afs/bin/volserver -cmd >> /usr/afs/bin/salvager -cell plm.cell -noauth I changed the above line including ``-cmd /usr/afs/bin/vlserver''. Then: ./vos create -server host.name -partition /vicepa -name root.afs -cell plm.cell -noauth Volume 274141546154 created on partition /vicepa of plmcvs.dia.uniroma3.it === OK ./bos shutdown host.name -wait bos: a pioctl failed (getting tickets) bos: running unauthenticated File server restart/shutdown received at Thu Mar 18 14:55:43 2004 File server has terminated normally at Thu Mar 18 14:55:43 2004 === OK pkill bosserver === OK I added afs to the running services, rebooted the machine and everything stops after: Starting AFS services... File server has started at Thu Mar 18 15:13:20 2004 <<>> What am I missing now? I'm followind this document: http://www.debianplanet.org/node.php?id=816 converting it to gentoo. Can anyone tell me the steps I'm missing to have a kerberized afs cell? Please!!! :) -- Sensei f u cn rd ths u r usng unx From senseiwa@tin.it Thu Mar 18 15:10:19 2004 From: senseiwa@tin.it (Sensei) Date: Thu, 18 Mar 2004 16:10:19 +0100 Subject: [OpenAFS] VOS: Always problems!!! In-Reply-To: <4059AFDB.7090505@tin.it> References: <40598DC2.4010400@tin.it> <4059A106.3000901@rzg.mpg.de> <4059AFDB.7090505@tin.it> Message-ID: <4059BBDB.9070901@tin.it> Sensei wrote: > Starting AFS services... > File server has started at Thu Mar 18 15:13:20 2004 > > <<>> After a loooooooong while it continues saying it cannot mount /afs --- that's good. Anyway, I can't do a klog. I log in as root obtaining the admin/admin ticket but nothing, klog asks for a password and then says I entered an invalid password... -- Sensei f u cn rd ths u r usng unx From joshua.johnson@ftlsys.com Thu Mar 18 16:30:23 2004 From: joshua.johnson@ftlsys.com (Joshua Johnson) Date: Thu, 18 Mar 2004 10:30:23 -0600 Subject: [OpenAFS] Trouble with download of Windows 1.3.600 .exe file Message-ID: <200403181030.23143.joshua.johnson@ftlsys.com> Perhaps someone could verify the correctness of the .exe file on the server? I have downloaded OpenAFS Windows 1.3.6000 from Web page twice and ftp once and can't seem to get entire archive. I logged in anonFtp to www.openafs.org and ls -l shows same file length as what I have. ls -l locally shows: (UID, GID, and perms changed by me) -****** 1 nnnn nnnn 10105197 2004-03-18 09:15 OpenAFSforWindows-1-3-6000.exe ls -l on ftp shows: -rwxrwxr-x 1 101 1003 10105197 Mar 18 01:44 OpenAFSforWindows-1-3-6000.exe md5sum local shows: 45ab8bcff23907d9d10e719b8b662d45 OpenAFSforWindows-1-3-6000.exe (Which doesn't match the web page or the .md5 for this file ... of course) The OpenAFS.....exe.md5 from the ftp or web contains and MD5 of: d86010ae673c41d71fa9b7ed4d7f6839 OpenAFSforWindows-1-3-6000.exe NSIS installer complains that the archive is corrupted or incomplete. Any/All help appreciated. Best Regards, Joshua Johnson From tcreedon@easystreet.com Thu Mar 18 17:03:07 2004 From: tcreedon@easystreet.com (ted creedon) Date: Thu, 18 Mar 2004 09:03:07 -0800 Subject: [OpenAFS] ICMP packets In-Reply-To: Message-ID: <20040318170307.BBE9A294D6@smtpauth.easystreet.com> I meant as a keep alive probe, not for data. tedc -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Derrick J Brashear Sent: Wednesday, March 17, 2004 8:45 PM To: openafs-info@openafs.org Subject: Re: [OpenAFS] ICMP packets On Wed, 17 Mar 2004, ted creedon wrote: > Why are ICMP packets used for AFS? They are? > Normally a firewall would drop pings. Only if you configure them to. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From jaltman@columbia.edu Thu Mar 18 17:14:05 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 18 Mar 2004 12:14:05 -0500 Subject: [OpenAFS] Trouble with download of Windows 1.3.600 .exe file In-Reply-To: <200403181030.23143.joshua.johnson@ftlsys.com> References: <200403181030.23143.joshua.johnson@ftlsys.com> Message-ID: <4059D8DD.60200@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms010203050006070703070702 Content-Type: multipart/alternative; boundary="------------040107070502030400010408" This is a multi-part message in MIME format. --------------040107070502030400010408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Problem confirmed. New binaries have been uploaded with an MD5 hash of: da97b2edc6f6b5886150616fff72b448 Jeffrey Altman Joshua Johnson wrote: >Perhaps someone could verify the correctness of the .exe file on the server? > > --------------040107070502030400010408 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Problem confirmed.  New binaries have been uploaded with an MD5 hash of:

     da97b2edc6f6b5886150616fff72b448

Jeffrey Altman


Joshua Johnson wrote:
Perhaps someone could verify the correctness of the .exe file on the server?

--------------040107070502030400010408-- --------------ms010203050006070703070702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxODE3MTQwNVowIwYJKoZIhvcNAQkEMRYEFA9U5+6rvK63 axtBG0Db7KU4kTiWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAJ6m6ytsuZWCtjFNmAsjZzQ/8Zo+O xxYe76H/9DXRH2KLMLrjfbD0w1o1efvJPxtYLaXtvA1aAPhqLm7kSCy/7jjIzyuuOpn75XNM ThmJN22zqNZzcnJr2Dxd5weoYakc5xwRPHY4YZVlOfD86TAGnm4yztLuwIUsPXzihwRt/sdr BmujiX5yizFXzK/Ab4hWLZLtElaxToM1aKznajBOXzsWStoCvow0fWaDQbj9JtukVP9sP4OK akDw/sQxAWZ/LWx0zpX5PBcLvhCjXbAf7Gxx5oaTNcvfITMn6nAgjwUFGVX5aVjBN71Rexz0 oaUO3jPQCrrFkq+ONqa8R7tdTAAAAAAAAA== --------------ms010203050006070703070702-- From dwb7@ccmr.cornell.edu Thu Mar 18 17:21:18 2004 From: dwb7@ccmr.cornell.edu (David Botsch) Date: Thu, 18 Mar 2004 12:21:18 -0500 Subject: [OpenAFS] res-search in x86_64 Message-ID: <20040318172118.GC3420@domino.ccmr.cornell.edu> Referencing: https://lists.openafs.org/pipermail/openafs-info/2004-January/011920.html Was a solution found to the -- configure: error: Unable to find res_search function problem in afs-krb5 (specifically, here, Fedora Core 1 on amd64 with openafs-1.2.11)? thnx. ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7@ccmr.cornell.edu ******************************** From jhutz@cmu.edu Thu Mar 18 17:50:44 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 18 Mar 2004 12:50:44 -0500 Subject: [OpenAFS] ICMP packets In-Reply-To: <20040318002904.89925B098@smtpauth.easystreet.com> References: <20040318002904.89925B098@smtpauth.easystreet.com> Message-ID: <171670000.1079632244@mariner.pc.cs.cmu.edu> On Wednesday, March 17, 2004 16:29:04 -0800 ted creedon wrote: > Why are ICMP packets used for AFS? AFS neither transmits nor intercepts any ICMP traffic. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From rees@umich.edu Thu Mar 18 18:07:06 2004 From: rees@umich.edu (Jim Rees) Date: Thu, 18 Mar 2004 13:07:06 -0500 Subject: [OpenAFS] ICMP packets In-Reply-To: "ted creedon", Thu, 18 Mar 2004 09:03:07 PST Message-ID: <20040318180706.2A8CF20992@citi.umich.edu> Afs does not use icmp for any purpose. From drosih@rpi.edu Thu Mar 18 18:49:21 2004 From: drosih@rpi.edu (Garance A Drosihn) Date: Thu, 18 Mar 2004 13:49:21 -0500 Subject: [OpenAFS] ICMP packets In-Reply-To: References: <20040318002904.89925B098@smtpauth.easystreet.com> Message-ID: At 12:17 AM -0500 3/18/04, Derek Atkins wrote: >Derrick J Brashear writes: > >>> Normally a firewall would drop pings. >> >> Only if you configure them to. > >And such a firewall is configured incorrectly. However, some firewwalls are configured to "throttle" ICMP packets, as a safeguard to various DOS problems that pop up. In that case, it's hard to argue that they are configured "wrong"... By "hard to argue", I mean I can talk until I'm blue in the face, but the person responsible for the firewall is not going to change anything. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From tcreedon@easystreet.com Thu Mar 18 19:07:23 2004 From: tcreedon@easystreet.com (ted creedon) Date: Thu, 18 Mar 2004 11:07:23 -0800 Subject: [OpenAFS] ICMP packets In-Reply-To: Message-ID: <20040318190723.7F4A5294E4@smtpauth.easystreet.com> Thanks for the lead on Bellovin's book. I'm getting an "ERROR: Problem at version: wrong type for that item" on port 88 (KRB5). ICMP is not involved. I'm using kaserver. Other than that everything seems to be working fine. -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Garance A Drosihn Sent: Thursday, March 18, 2004 10:49 AM To: Derek Atkins; Derrick J Brashear Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] ICMP packets At 12:17 AM -0500 3/18/04, Derek Atkins wrote: >Derrick J Brashear writes: > >>> Normally a firewall would drop pings. >> >> Only if you configure them to. > >And such a firewall is configured incorrectly. However, some firewwalls are configured to "throttle" ICMP packets, as a safeguard to various DOS problems that pop up. In that case, it's hard to argue that they are configured "wrong"... By "hard to argue", I mean I can talk until I'm blue in the face, but the person responsible for the firewall is not going to change anything. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From shadow@dementia.org Thu Mar 18 19:13:31 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 18 Mar 2004 14:13:31 -0500 (EST) Subject: [OpenAFS] ICMP packets In-Reply-To: <20040318190723.7F4A5294E4@smtpauth.easystreet.com> References: <20040318190723.7F4A5294E4@smtpauth.easystreet.com> Message-ID: kaserver doesn't talk krb5, so that's no shock. what's trying to do krb5? On Thu, 18 Mar 2004, ted creedon wrote: > Thanks for the lead on Bellovin's book. > > I'm getting an "ERROR: Problem at version: wrong type for that item" on port > 88 (KRB5). ICMP is not involved. I'm using kaserver. > > Other than that everything seems to be working fine. > > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] > On Behalf Of Garance A Drosihn > Sent: Thursday, March 18, 2004 10:49 AM > To: Derek Atkins; Derrick J Brashear > Cc: openafs-info@openafs.org > Subject: Re: [OpenAFS] ICMP packets > > At 12:17 AM -0500 3/18/04, Derek Atkins wrote: > >Derrick J Brashear writes: > > > >>> Normally a firewall would drop pings. > >> > >> Only if you configure them to. > > > >And such a firewall is configured incorrectly. > > However, some firewwalls are configured to "throttle" ICMP packets, > as a safeguard to various DOS problems that pop up. In that case, > it's hard to argue that they are configured "wrong"... By "hard > to argue", I mean I can talk until I'm blue in the face, but the > person responsible for the firewall is not going to change anything. > > -- > Garance Alistair Drosehn = gad@gilead.netel.rpi.edu > Senior Systems Programmer or gad@freebsd.org > Rensselaer Polytechnic Institute or drosih@rpi.edu > _______________________________________________ > 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 > From kwc@citi.umich.edu Thu Mar 18 19:23:31 2004 From: kwc@citi.umich.edu (Kevin Coffman) Date: Thu, 18 Mar 2004 14:23:31 -0500 Subject: [OpenAFS] ICMP packets In-Reply-To: Your message of "Thu, 18 Mar 2004 11:07:23 PST." <20040318190723.7F4A5294E4@smtpauth.easystreet.com> Message-ID: <20040318192331.451702186F@citi.umich.edu> > I'm getting an "ERROR: Problem at version: wrong type for that item" on port > 88 (KRB5). ICMP is not involved. I'm using kaserver. This sounds like Ethereal? It seems to think that everthing for port 88 is a K5 packet, when in fact it is a K4 packet being sent to/from the K5 port. From mdw@umich.edu Thu Mar 18 19:29:38 2004 From: mdw@umich.edu (Marcus Watts) Date: Thu, 18 Mar 2004 14:29:38 -0500 Subject: [OpenAFS] ICMP packets In-Reply-To: Your message of "Thu, 18 Mar 2004 14:13:31 EST." Message-ID: <200403181930.OAA20177@quince.ifs.umich.edu> Derrick J Brashear writes: > kaserver doesn't talk krb5, so that's no shock. > > what's trying to do krb5? ... > > I'm getting an "ERROR: Problem at version: wrong type for that item" on port > > 88 (KRB5). ICMP is not involved. I'm using kaserver. ... Port 88 should probably actually be called "kerberos". It's used for both k4 and k5, and as it happens kaserver services k4 requests on both port 88 and 750 (as well as for rx on port 7004). I'm not sure where that error message comes from -- I believe kaserver should say "packet version number unknown". Might be nice to know more about how that message was generated or recorded. -Marcus Watts UM ITCS Umich Systems Group From tcreedon@easystreet.com Thu Mar 18 19:45:48 2004 From: tcreedon@easystreet.com (ted creedon) Date: Thu, 18 Mar 2004 11:45:48 -0800 Subject: [OpenAFS] ICMP packets In-Reply-To: <200403181930.OAA20177@quince.ifs.umich.edu> Message-ID: <20040318194548.9FC6EB090@smtpauth.easystreet.com> That message is in the first 2 packets when my XP client asks for a token from the server. (ie the client sends "ERROR: Problem at version: wrong type for that item" in the first packet and the server responds with the same Info in the response packet. Yes it is ethereal. http://www.sebby.org/afs/afs-and-firewalls-lisa2002-6up.pdf states that the Win 2K client does use port 88. It does work. The message is generated when I "discard these tokens" and "obtain new tokens" using the windows AFS client GUI. I don't see any other packets. UDP ports 7000-7010 are open at the firewal Source Destination Protocol Info 1 0.000000 c-xxx.client.comcast.net reddog.ted-doris.fam KRB5 ERROR: Problem at version: Wrong type for that item 4 0.069724 reddog.ted-doris.fam c-xxx.client.comcast.net KRB5 ERROR: Problem at version: Wrong type for that item Provides tokens that work for admin. -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Marcus Watts Sent: Thursday, March 18, 2004 11:30 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] ICMP packets Derrick J Brashear writes: > kaserver doesn't talk krb5, so that's no shock. > > what's trying to do krb5? ... > > I'm getting an "ERROR: Problem at version: wrong type for that item" on port > > 88 (KRB5). ICMP is not involved. I'm using kaserver. ... Port 88 should probably actually be called "kerberos". It's used for both k4 and k5, and as it happens kaserver services k4 requests on both port 88 and 750 (as well as for rx on port 7004). I'm not sure where that error message comes from -- I believe kaserver should say "packet version number unknown". Might be nice to know more about how that message was generated or recorded. -Marcus Watts UM ITCS Umich Systems Group _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From tcreedon@easystreet.com Thu Mar 18 20:18:40 2004 From: tcreedon@easystreet.com (ted creedon) Date: Thu, 18 Mar 2004 12:18:40 -0800 Subject: [OpenAFS] ICMP packets In-Reply-To: <200403181930.OAA20177@quince.ifs.umich.edu> Message-ID: <20040318201841.0FA9A294DB@smtpauth.easystreet.com> I grepped the sources for "Wrong type" and got nothing. Possibly Win is inserting the message and kaserver says "fine. Here's your token anyway"..? -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Marcus Watts Sent: Thursday, March 18, 2004 11:30 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] ICMP packets Derrick J Brashear writes: > kaserver doesn't talk krb5, so that's no shock. > > what's trying to do krb5? ... > > I'm getting an "ERROR: Problem at version: wrong type for that item" on port > > 88 (KRB5). ICMP is not involved. I'm using kaserver. ... Port 88 should probably actually be called "kerberos". It's used for both k4 and k5, and as it happens kaserver services k4 requests on both port 88 and 750 (as well as for rx on port 7004). I'm not sure where that error message comes from -- I believe kaserver should say "packet version number unknown". Might be nice to know more about how that message was generated or recorded. -Marcus Watts UM ITCS Umich Systems Group _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From allbery@ece.cmu.edu Thu Mar 18 20:24:15 2004 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu, 18 Mar 2004 15:24:15 -0500 Subject: [OpenAFS] ICMP packets In-Reply-To: <20040318194548.9FC6EB090@smtpauth.easystreet.com> References: <20040318194548.9FC6EB090@smtpauth.easystreet.com> Message-ID: <1079641455.1812.17.camel@pyanfar.ece.cmu.edu> On Thu, 2004-03-18 at 14:45, ted creedon wrote: > Yes it is ethereal. Use a program other than ethereal. That error message is from ethereal itself, complaining that it expected to see a KerberosV packet but found something else instead (namely a KerberosIV packet). -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From dwb7@ccmr.cornell.edu Thu Mar 18 20:24:59 2004 From: dwb7@ccmr.cornell.edu (David Botsch) Date: Thu, 18 Mar 2004 15:24:59 -0500 Subject: [OpenAFS] res-search in x86_64 In-Reply-To: <20040318172118.GC3420@domino.ccmr.cornell.edu>; from dwb7@ccmr.cornell.edu on Thu, Mar 18, 2004 at 12:21:18 -0500 References: <20040318172118.GC3420@domino.ccmr.cornell.edu> Message-ID: <20040318202459.GE3420@domino.ccmr.cornell.edu> Time to reply to myself... gotten around the below problem as far as compiling, it seems... but, pam doesn't quite compile with the error: /usr/bin/ld: /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a(client.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [pam_afs.so.1] Error 1 from: + cc -shared -Xlinker -x -o pam_afs.so.1 afs_setcred.o afs_auth.o afs_util.o afs_account.o afs_session.o afs_password.o afs_pam_msg.o afs_message.o AFS_component_version_number.o /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/libprot.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/libubik.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/libauth.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/librxkad.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/libsys.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/libdes.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/librx.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/liblwp.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/libaudit.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/libcmd.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/libcom_err.a /usr/src/redhat/BUILD/openafs-1.2.11/lib/util.a -lresolv Hrm... On 2004.03.18 12:21 David Botsch wrote: > Referencing: > https://lists.openafs.org/pipermail/openafs-info/2004-January/011920.html > > Was a solution found to the -- configure: error: Unable to find > res_search function > > problem in afs-krb5 (specifically, here, Fedora Core 1 on amd64 with > openafs-1.2.11)? > > thnx. > > ******************************** > David William Botsch > Consultant/Advisor II > CCMR Computing Facility > dwb7@ccmr.cornell.edu > ******************************** > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7@ccmr.cornell.edu ******************************** From msantoro@pobox.com Thu Mar 18 20:28:27 2004 From: msantoro@pobox.com (Marc Santoro) Date: Thu, 18 Mar 2004 14:28:27 -0600 (CST) Subject: [OpenAFS] AFS CopyOnWrite problem Message-ID: We have two OpenAFS fileservers. After a reboot, we can no longer create or remove files in certain directories on one of the non-replicated volumes on one of the servers, as well as removing or renaming these directories. Files in that directory can be changed (though not removed or renamed), and files/directories in subdirectories work as expected. The failed commands print "No space left on device". There is plenty of space left. Ex: $ touch a touch: cannot touch `a': No space left on device $ touch foo/a (where foo is a pre-existing empty directory) $ rm foo/a $ rmdir foo rmdir: `foo': No space left on device Both AFS fileservers are running 1.2.11, on Linux 2.4.25 (Debian packages). in the FileLog, we see: Thu Mar 18 14:06:44 2004 CopyOnWrite failed: Partition /vicepa that contains volume 536870918 may be out of free inodes(errno = 17) Once for each error. The filesystem has plenty of free inodes; files can be created in other directories. Both servers have been rebooted, and "salvage"d, to no avail. Salvage found some inode/vnode version discrepancies, but nothing else. Help! :) From shadow@dementia.org Thu Mar 18 20:31:21 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 18 Mar 2004 15:31:21 -0500 (EST) Subject: [OpenAFS] res-search in x86_64 In-Reply-To: <20040318202459.GE3420@domino.ccmr.cornell.edu> References: <20040318172118.GC3420@domino.ccmr.cornell.edu> <20040318202459.GE3420@domino.ccmr.cornell.edu> Message-ID: Skip pam. Or link the shared versions of libafsrpc and libafsauthent, but there are ramifications if you have a long-running program On Thu, 18 Mar 2004, David Botsch wrote: > Time to reply to myself... > > gotten around the below problem as far as compiling, it seems... > > but, pam doesn't quite compile with the error: > /usr/bin/ld: > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a(client.o): > relocation R_X86_64_32 can not be used when making a shared object; > recompile with -fPIC > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a: could not read > symbols: Bad value > collect2: ld returned 1 exit status > make: *** [pam_afs.so.1] Error 1 > > from: > + cc -shared -Xlinker -x -o pam_afs.so.1 afs_setcred.o afs_auth.o > afs_util.o afs_account.o afs_session.o afs_password.o afs_pam_msg.o > afs_message.o AFS_component_version_number.o > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libprot.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libubik.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libauth.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/librxkad.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libsys.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libdes.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/librx.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/liblwp.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libaudit.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libcmd.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libcom_err.a > /usr/src/redhat/BUILD/openafs-1.2.11/lib/util.a -lresolv > > Hrm... > > On 2004.03.18 12:21 David Botsch wrote: > > Referencing: > > https://lists.openafs.org/pipermail/openafs-info/2004-January/011920.html > > > > Was a solution found to the -- configure: error: Unable to find > > res_search function > > > > problem in afs-krb5 (specifically, here, Fedora Core 1 on amd64 with > > openafs-1.2.11)? > > > > thnx. > > > > ******************************** > > David William Botsch > > Consultant/Advisor II > > CCMR Computing Facility > > dwb7@ccmr.cornell.edu > > ******************************** > > _______________________________________________ > > OpenAFS-info mailing list > > OpenAFS-info@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- > ******************************** > David William Botsch > Consultant/Advisor II > CCMR Computing Facility > dwb7@ccmr.cornell.edu > ******************************** > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From dwb7@ccmr.cornell.edu Thu Mar 18 20:53:02 2004 From: dwb7@ccmr.cornell.edu (David Botsch) Date: Thu, 18 Mar 2004 15:53:02 -0500 Subject: [OpenAFS] res-search in x86_64 In-Reply-To: ; from shadow@dementia.org on Thu, Mar 18, 2004 at 15:31:21 -0500 References: <20040318172118.GC3420@domino.ccmr.cornell.edu> <20040318202459.GE3420@domino.ccmr.cornell.edu> Message-ID: <20040318205302.GG3420@domino.ccmr.cornell.edu> don't think we can skip pam as it's used by gdm, sshd, etc to auth people and set up the environment. I suppose I can modify the Makefile, however, presumably there's a reason you don't use libafsrpc and libafsauthent as you imply below... what are the implications? On 2004.03.18 15:31 Derrick J Brashear wrote: > Skip pam. Or link the shared versions of libafsrpc and libafsauthent, > but > there are ramifications if you have a long-running program > > > On Thu, 18 Mar 2004, David Botsch wrote: > > > Time to reply to myself... > > > > gotten around the below problem as far as compiling, it seems... > > > > but, pam doesn't quite compile with the error: > > /usr/bin/ld: > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a(client.o): > > relocation R_X86_64_32 can not be used when making a shared object; > > recompile with -fPIC > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a: could not read > > symbols: Bad value > > collect2: ld returned 1 exit status > > make: *** [pam_afs.so.1] Error 1 > > > > from: > > + cc -shared -Xlinker -x -o pam_afs.so.1 afs_setcred.o afs_auth.o > > afs_util.o afs_account.o afs_session.o afs_password.o afs_pam_msg.o > > afs_message.o AFS_component_version_number.o > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libkauth.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libprot.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libubik.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libauth.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/librxkad.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libsys.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libdes.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/librx.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/liblwp.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libaudit.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libcmd.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/libcom_err.a > > /usr/src/redhat/BUILD/openafs-1.2.11/lib/util.a -lresolv > > > > Hrm... > > > > On 2004.03.18 12:21 David Botsch wrote: > > > Referencing: > > > > https://lists.openafs.org/pipermail/openafs-info/2004-January/011920.html > > > > > > Was a solution found to the -- configure: error: Unable to find > > > res_search function > > > > > > problem in afs-krb5 (specifically, here, Fedora Core 1 on amd64 > with > > > openafs-1.2.11)? > > > > > > thnx. > > > > > > ******************************** > > > David William Botsch > > > Consultant/Advisor II > > > CCMR Computing Facility > > > dwb7@ccmr.cornell.edu > > > ******************************** > > > _______________________________________________ > > > OpenAFS-info mailing list > > > OpenAFS-info@openafs.org > > > https://lists.openafs.org/mailman/listinfo/openafs-info > > > > -- > > ******************************** > > David William Botsch > > Consultant/Advisor II > > CCMR Computing Facility > > dwb7@ccmr.cornell.edu > > ******************************** > > _______________________________________________ > > 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 > -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7@ccmr.cornell.edu ******************************** From shadow@dementia.org Thu Mar 18 20:57:13 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 18 Mar 2004 15:57:13 -0500 (EST) Subject: [OpenAFS] res-search in x86_64 In-Reply-To: <20040318205302.GG3420@domino.ccmr.cornell.edu> References: <20040318172118.GC3420@domino.ccmr.cornell.edu> <20040318202459.GE3420@domino.ccmr.cornell.edu> <20040318205302.GG3420@domino.ccmr.cornell.edu> Message-ID: On Thu, 18 Mar 2004, David Botsch wrote: > don't think we can skip pam as it's used by gdm, sshd, etc to auth > people and set up the environment. then get newer compiler tools that support relocating static objects. > I suppose I can modify the Makefile, however, presumably there's a > reason you don't use libafsrpc and libafsauthent as you imply below... > what are the implications? a non-pthreaeded process will end up with threads as a side effect of using this module From dwb7@ccmr.cornell.edu Thu Mar 18 21:04:14 2004 From: dwb7@ccmr.cornell.edu (David Botsch) Date: Thu, 18 Mar 2004 16:04:14 -0500 Subject: [OpenAFS] res-search in x86_64 In-Reply-To: ; from shadow@dementia.org on Thu, Mar 18, 2004 at 15:57:13 -0500 References: <20040318172118.GC3420@domino.ccmr.cornell.edu> <20040318202459.GE3420@domino.ccmr.cornell.edu> <20040318205302.GG3420@domino.ccmr.cornell.edu> Message-ID: <20040318210414.GI3420@domino.ccmr.cornell.edu> From glancing around, this seems to be how gcc is under Fedora Core 1 x86 (more picky). Gonna' try building with -fPIC and see what happens. On 2004.03.18 15:57 Derrick J Brashear wrote: > On Thu, 18 Mar 2004, David Botsch wrote: > > > don't think we can skip pam as it's used by gdm, sshd, etc to auth > > people and set up the environment. > then get newer compiler tools that support relocating static objects. > > > > I suppose I can modify the Makefile, however, presumably there's a > > reason you don't use libafsrpc and libafsauthent as you imply > below... > > what are the implications? > > > a non-pthreaeded process will end up with threads as a side effect of > using this module > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7@ccmr.cornell.edu ******************************** From shadow@dementia.org Thu Mar 18 21:17:58 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 18 Mar 2004 16:17:58 -0500 (EST) Subject: [OpenAFS] res-search in x86_64 In-Reply-To: <20040318210414.GI3420@domino.ccmr.cornell.edu> References: <20040318172118.GC3420@domino.ccmr.cornell.edu> <20040318202459.GE3420@domino.ccmr.cornell.edu> <20040318205302.GG3420@domino.ccmr.cornell.edu> <20040318210414.GI3420@domino.ccmr.cornell.edu> Message-ID: On Thu, 18 Mar 2004, David Botsch wrote: > From glancing around, this seems to be how gcc is under Fedora Core 1 > x86 (more picky). Gonna' try building with -fPIC and see what happens. that should work From nneul@umr.edu Thu Mar 18 21:43:27 2004 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 18 Mar 2004 15:43:27 -0600 Subject: [OpenAFS] AFS CopyOnWrite problem Message-ID: <5C51DC2B8353AB4BA2CD04B34F2EE79C115F75@umr-umail1.umr.edu> We had this same problem recently... also caused volumes to repeatedly go offline. We wound up clearing the server to another and reinstalling. One possibility we considered that it may be volumes with too many clones - i.e. crud left over that is no longer referenced, but stil occupying refcounts, but didn't have any opportunity to investigate in detail.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-6679 UMR Information Technology Fax: (573) 341-4216 =20 > -----Original Message----- > From: openafs-info-admin@openafs.org=20 > [mailto:openafs-info-admin@openafs.org] On Behalf Of Marc Santoro > Sent: Thursday, March 18, 2004 2:28 PM > To: openafs-info@openafs.org > Subject: [OpenAFS] AFS CopyOnWrite problem >=20 > We have two OpenAFS fileservers. After a reboot, we can no=20 > longer create > or remove files in certain directories on one of the non-replicated > volumes on one of the servers, as well as removing or renaming these > directories. Files in that directory can be changed (though=20 > not removed or > renamed), and files/directories in subdirectories work as expected. >=20 > The failed commands print "No space left on device". There is=20 > plenty of > space left. >=20 > Ex: > $ touch a > touch: cannot touch `a': No space left on device > $ touch foo/a (where foo is a pre-existing empty directory) > $ rm foo/a > $ rmdir foo > rmdir: `foo': No space left on device >=20 > Both AFS fileservers are running 1.2.11, on Linux 2.4.25 (Debian > packages). >=20 > in the FileLog, we see: >=20 > Thu Mar 18 14:06:44 2004 CopyOnWrite failed: Partition /vicepa that > contains volume 536870918 may be out of free inodes(errno =3D 17) >=20 > Once for each error. The filesystem has plenty of free=20 > inodes; files can > be created in other directories. >=20 > Both servers have been rebooted, and "salvage"d, to no avail. Salvage > found some inode/vnode version discrepancies, but nothing else. >=20 > Help! :) > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >=20 >=20 From dative@sukrahelitek.com Thu Mar 18 22:27:07 2004 From: dative@sukrahelitek.com (Benjamin P Myers) Date: Thu, 18 Mar 2004 16:27:07 -0600 Subject: [OpenAFS] vos move failure Message-ID: <200403181627.07112.dative@sukrahelitek.com> Hi folks, I'm having some trouble with 'balance' which brought this to my attention= , but=20 i can't move the volume manually, either. Can anyone suggest what my next= =20 step should be to fix this? Thanks kindly, Ben # vos move vishnu b vishnu c -verbose Starting transaction on source volume 536871292 ... done Cloning source volume 536871292 ... done Ending the transaction on the source volume 536871292 ... done Starting transaction on the cloned volume 536871678 ... done Creating the destination volume 536871292 ...Failed to create the destina= tion=20 volume 536871292 : Input/output error vos move: operation interrupted, cleanup in progress... clear transaction contexts access VLDB move incomplete - attempt cleanup of target partition - no guarantee cleanup complete - user verify desired result # bos salvage vishnu c 536871292 Starting salvage. bos: salvage completed # vos zap vishnu c 536871292 Warning: Entry for volume number 536871292 exists in VLDB (but we're zapp= ing=20 it anyway!) Volume 536871292 deleted Thu Mar 18 11:58:20 2004 Set Debug On level =3D 125 Thu Mar 18 16:06:40 2004 1 Volser: Clone: Cloning volume 536871292 to new= =20 volume 536871678 Thu Mar 18 16:06:41 2004 1 Volser: CreateVolume: Unable to create the vol= ume;=20 aborted, error code 103 Thu Mar 18 16:06:41 2004 : Software caused connection abort Thu Mar 18 16:06:45 2004 VAttachVolume: Error reading volume header=20 /vicepc/V0536871292.vol Thu Mar 18 16:06:46 2004 1 Volser: Delete: volume 536871678 deleted Thu Mar 18 16:12:07 2004 1 Volser: Delete: volume 536871292 deleted @(#) OpenAFS 1.2.11 built 2004-02-13=20 03/18/2004 16:11:26 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/salvager /vic= epc=20 536871292) 03/18/2004 16:11:27 SALVAGING VOLUME 536871292. 03/18/2004 16:11:27 Missing inode in volume header (Volume information) 03/18/2004 16:11:27 Missing inode in volume header (Volume information);=20 recreating 03/18/2004 16:11:27 Warning: the name of volume 536871292 is now=20 "bogus.536871292" 03/18/2004 16:11:27 Missing inode in volume header (small inode index);=20 recreating 03/18/2004 16:11:27 Missing inode in volume header (large inode index);=20 recreating 03/18/2004 16:11:27 No header file for volume 536871292; creating=20 /vicepc/V0536871292.vol 03/18/2004 16:11:27 iinc failed. inode 1791001362464 errno 9 03/18/2004 16:11:27 iinc failed on link table, errno =3D 9 03/18/2004 16:11:27 iinc failed on link table, errno =3D 9 03/18/2004 16:11:27 Salvaged bogus.536871292 (536871292): 0 files, 0 bloc= ks From antispamid2003@yahoo.com Thu Mar 18 23:09:26 2004 From: antispamid2003@yahoo.com (Pamela Goetz) Date: Thu, 18 Mar 2004 15:09:26 -0800 (PST) Subject: [OpenAFS] "Integrated Login Failed" under Windows 2000 Message-ID: <20040318230926.37502.qmail@web61006.mail.yahoo.com> Whenever I restart my Windows 2000 PC (currently automatically login into Administrator account - as I am still in the process of installing/configuring it), It gives me the following error: AFS LOGON ERROR "Integrated Login Failed: " (the garbled text looks like an encypted password?) I click OK and then the "AFS Client Wizard" is displayed and reads: "The AFS Client service has not yet started". I then click "Next" and the client seems to have been started, prompting me for AFS cell, user name and password. The AFS cell edit box already contains the correct value. The user name edit, on the other hand, contains 'Administrator' - which is of course incorrect. I type in my AFS username and password, click 'Next, and everything works fine (I get the message: "The AFS Client is ready for use". Now... while it is very nice that I can make my AFS client on Windows 2000 work, it is very inconvenient to always have to type the username and password whenever I logon. So, my question is: How do make the AFS client service start up automatically and automatically logon using the username & password that work so perfectly when I enter them manually? I am using AFS Version 1.2.10 Thanks, Pam __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com From jaltman@columbia.edu Thu Mar 18 23:14:58 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 18 Mar 2004 18:14:58 -0500 Subject: [OpenAFS] "Integrated Login Failed" under Windows 2000 In-Reply-To: <20040318230926.37502.qmail@web61006.mail.yahoo.com> References: <20040318230926.37502.qmail@web61006.mail.yahoo.com> Message-ID: <405A2D72.10805@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms050105070203000805020306 Content-Type: multipart/alternative; boundary="------------030600030100000603070601" This is a multi-part message in MIME format. --------------030600030100000603070601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The username used to login to windows must match the username used to obtain tokens for AFS. Otherwise, the AFS Integrated Logon cannot work. Jeffrey Altman Pamela Goetz wrote: >Whenever I restart my Windows 2000 PC (currently automatically login >into Administrator account - as I am still in the process of >installing/configuring it), It gives me the following error: > >AFS LOGON ERROR >"Integrated Login Failed: " > >(the garbled text looks like an encypted password?) > >I click OK and then the "AFS Client Wizard" is displayed and reads: >"The AFS Client service has not yet started". > >I then click "Next" and the client seems to have been started, >prompting me for AFS cell, user name and password. The AFS cell edit >box already contains the correct value. The user name edit, on the >other hand, contains 'Administrator' - which is of course incorrect. I >type in my AFS username and password, click 'Next, and everything works >fine (I get the message: "The AFS Client is ready for use". > >Now... while it is very nice that I can make my AFS client on Windows >2000 work, it is very inconvenient to always have to type the username >and password whenever I logon. So, my question is: > >How do make the AFS client service start up automatically and >automatically logon using the username & password that work so >perfectly when I enter them manually? > >I am using AFS Version 1.2.10 > > >Thanks, >Pam > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - More reliable, more storage, less spam >http://mail.yahoo.com >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > --------------030600030100000603070601 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The username used to login to windows must match the username used to obtain
tokens for AFS.  Otherwise, the AFS Integrated Logon cannot work.

Jeffrey Altman


Pamela Goetz wrote:
Whenever I restart my Windows 2000 PC (currently automatically login
into Administrator account - as I am still in the process of
installing/configuring it), It gives me the following error:

AFS LOGON ERROR
"Integrated Login Failed: <some garbled text>"

(the garbled text looks like an encypted password?)

I click OK and then the "AFS Client Wizard" is displayed and reads:
"The  AFS Client service has not yet started".

I then click "Next" and the client seems to have been started,
prompting me for AFS cell, user name and password. The AFS cell edit
box already contains the correct value. The user name edit, on the
other hand, contains 'Administrator' - which is of course incorrect. I
type in my AFS username and password, click 'Next, and everything works
fine (I get the message: "The AFS Client is ready for use".

Now... while it is very nice that I can make my AFS client on Windows
2000 work, it is very inconvenient to always have to type the username
and password whenever I logon. So, my question is:

How do make the AFS client service start up automatically and
automatically logon using the username & password that work so
perfectly when I enter them manually?

I am using AFS Version 1.2.10


Thanks,
Pam 



__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--------------030600030100000603070601-- --------------ms050105070203000805020306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxODIzMTQ1OFowIwYJKoZIhvcNAQkEMRYEFDordWGG8HnJ wmqtBLJX23mUUYyNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAK2Dr1rTeEYWEjVjzL9jBtr0sx6Rg QfdWOb0PJjIzvRrVb4Fm60ikqRdCq9y2iatO9agGsbC29vaG465X/v2cbWIfVP6bdsFkP+P6 9n6j9AZkjmaRIIuD65vsQECbVgEW154GgD+xqP7+9x7jM7sIO/GJtGco9SXtqn8imJl8HRR0 MZfqXgjEa+FipFW6K9+jl2UK3RNby/ndbg2MnLMP17VYTKPkD6XZpLvnINtfgmWYbDiSFny5 x6hoRLf6lv7ZGWKHrvzMVhsKMhW/VIJudXX4Akzz+Gjaur3W83o87sQyMbOI37gARkSvJV3K iwI+4f+5KyHsCymur184Tco+swAAAAAAAA== --------------ms050105070203000805020306-- From Sergio.Gelato@astro.su.se Tue Mar 16 17:51:14 2004 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Tue, 16 Mar 2004 18:51:14 +0100 Subject: [OpenAFS] Solaris x86 also crashes because of item 1434 In-Reply-To: <7200.1079451046@pabst.cs.uwm.edu> References: <7200.1079451046@pabst.cs.uwm.edu> Message-ID: <20040316175113.GB4184@hanuman.astro.su.se> * John Tang Boyland [2004-03-16 09:30:46 -0600]: > Last summer AFS bug #1434 was apparently fixed for Solaris 8 on SPARC, > but apparently not fixed for Solaris 8 on Intel. I was hoping Are you sure? The fix (by D.E.Engert) was to bracket the read_binding_file() call with a #ifndef AFS_SUN58_ENV, and I see that src/config/param.sunx86_58.h does define AFS_SUN58_ENV. > the latest openafs would fix this, but it appears that the > kernel module for 1.2.11 is the same as the one for 1.2.10. IIRC the problem was discovered when 1.2.9 was current, and the fix was integrated in 1.2.10. > I finally patched my system and now starting afs crashes the kernel. Meaning that you applied Sun's patch 108529-20 or newer? Are you using the binary tarballs from www.openafs.org or compiling your own? Can you run nm /kernel/fs/afs | grep read_binding_file ? The fix for 1434 removed all references to that symbol; if you don't see it, that means you don't have bug 1434. (You may have discovered a different bug.) > (I tried to set this as a comment to ticket #1434, but (1) I don't > know who would get the comment, and (2) guest is not allowed to > post comments and (3) rt.central.org doesn't mention how to create > a non-guest account.) I think the proper way to report bugs is to mail openafs-bugs@openafs.org. RT is apparently read-only for the likes of you and me. (That's OK with me.) From openafs@butchwax.com Thu Mar 18 23:42:51 2004 From: openafs@butchwax.com (John Morris) Date: 18 Mar 2004 17:42:51 -0600 Subject: [OpenAFS] no quorum elected Message-ID: Hi! My openafs system has this problem: # vos move root.mail kug /vicepa nixon /vicepa Could not lock entry for volume 536871065 u: no quorum elected I guessed that it was the 2004-01-10 bug, so I've been upgrading my servers. There are three file servers; I've upgraded two already from 1.2.9 to 1.2.11. The third still runs 1.2.9, and it's going to be scary upgrading it 'cause it's physically about 200 miles away from me, and the way the first two went, it's a coin-flip whether I'll need to get on the console. Anyway, I figured that getting 2 of 3 would give me a quorum, but the machines still have the same problem. Does this bug affect the whole system if only one machine is running the old version, or do I have a different problem? Thanks for any tips! John -- John Morris +1-512-480-0200x1002 From jhutz@cmu.edu Fri Mar 19 00:44:46 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 18 Mar 2004 19:44:46 -0500 Subject: [OpenAFS] no quorum elected In-Reply-To: References: Message-ID: <2014330000.1079657086@minbar.fac.cs.cmu.edu> On Thursday, March 18, 2004 17:42:51 -0600 John Morris wrote: > Hi! > > My openafs system has this problem: > > # vos move root.mail kug /vicepa nixon /vicepa > Could not lock entry for volume 536871065 > u: no quorum elected > > I guessed that it was the 2004-01-10 bug, so I've been upgrading my > servers. > > There are three file servers; I've upgraded two already from 1.2.9 to > 1.2.11. The third still runs 1.2.9, and it's going to be scary > upgrading it 'cause it's physically about 200 miles away from me, and > the way the first two went, it's a coin-flip whether I'll need to get > on the console. > > Anyway, I figured that getting 2 of 3 would give me a quorum, but the > machines still have the same problem. Does this bug affect the whole > system if only one machine is running the old version, or do I have a > different problem? The bug prevents establishment of quorum if the machine that should become coordinator (normally the one with the numerically-lowest IP address) is not running the new version. From stephen@physics.unc.edu Fri Mar 19 01:57:39 2004 From: stephen@physics.unc.edu (Stephen Joyce) Date: Thu, 18 Mar 2004 20:57:39 -0500 (EST) Subject: [OpenAFS] 1.3.6000 integrated logon? Message-ID: I'm testing the windows 1.3.6000 build--hoping it will solve several outstanding problems I've seen with OpenAFS 1.2.11 on windows. Can someone please confirm for me that obtaining tokens when logging into Windows works on this build? I have checked "Obtain AFS tokens when logging into Windows", and made sure that "Fail Logins Silently" is "No", but I do not get tokens when logging in. Neither is there any error message to indicate that the client is even attempting to contact a server, nor any record in the server logs. I've confirmed that toggling the "Obtain AFS tokens..." checkbox does indeed toggle HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider\LogonOptions. I'm attempting standard AFS authentication, against krb5/fakeka. I can obtain tokens manually on the client without problems and that shows up in the server logs as expected. Cheers, Stephen From tfitz@MIT.EDU Fri Mar 19 02:31:56 2004 From: tfitz@MIT.EDU (Tom Fitzgerald) Date: Thu, 18 Mar 2004 21:31:56 -0500 Subject: [OpenAFS] Retiring a partition In-Reply-To: <20040318230926.37502.qmail@web61006.mail.yahoo.com> References: <20040318230926.37502.qmail@web61006.mail.yahoo.com> Message-ID: <1079663516.25400.38.camel@sligo.mit.edu> I'm attempting to retire a vice partition, but after moving all volumes off it, it still contains two .vol files whose names correspond to existing volumes that used to be in that partition but are now elsewhere, and another hundred or so mystery files under the AFSIDat directory. vos listvldb confirms that no volumes of any kind are located there, and bos salvage has no effect on the partition. Is there any way to determine what these files are still being used for, if anything, and if not, why they got left there? None of the "vos move"s or "vos remsite"s reported any errors. Or is it safe to just wipe the partition and forget about it? This is on linux, so namei filesystem. From jaltman@columbia.edu Fri Mar 19 02:51:49 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 18 Mar 2004 21:51:49 -0500 Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: References: Message-ID: <405A6045.8010707@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms000807060302010008090705 Content-Type: multipart/alternative; boundary="------------050107080202080701030204" This is a multi-part message in MIME format. --------------050107080202080701030204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To be honest I have not even had time to look at afslogon.c yet. I just took a look at it and it scared me. There is a mixture of calls to LocalAlloc() followed by calls to free() on the allocated memory which is sure to cause memory corruption. I do not know if it works or does not work. However, the only changes to it since 1.2.10 are to the string used to identify the module when logging Events. Jeffrey Altman Stephen Joyce wrote: >I'm testing the windows 1.3.6000 build--hoping it will solve several >outstanding problems I've seen with OpenAFS 1.2.11 on windows. > >Can someone please confirm for me that obtaining tokens when logging into >Windows works on this build? > >I have checked "Obtain AFS tokens when logging into Windows", and made sure >that "Fail Logins Silently" is "No", but I do not get tokens when >logging in. Neither is there any error message to indicate that the client >is even attempting to contact a server, nor any record in the server logs. > >I've confirmed that toggling the "Obtain AFS tokens..." checkbox does >indeed toggle >HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider\LogonOptions. > >I'm attempting standard AFS authentication, against krb5/fakeka. I can >obtain tokens manually on the client without problems and that shows up in >the server logs as expected. > >Cheers, >Stephen >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > --------------050107080202080701030204 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit To be honest I have not even had time to look at afslogon.c
yet.  I just took a look at it and it scared me.  There
is a mixture of calls to LocalAlloc() followed by calls to
free() on the allocated memory which is sure to cause memory
corruption.

I do not know if it works or does not work.  However, the
only changes to it since 1.2.10 are to the string used to
identify the module when logging Events.

Jeffrey Altman


Stephen Joyce wrote:
I'm testing the windows 1.3.6000 build--hoping it will solve several
outstanding problems I've seen with OpenAFS 1.2.11 on windows.

Can someone please confirm for me that obtaining tokens when logging into
Windows works on this build?

I have checked "Obtain AFS tokens when logging into Windows", and made sure
that "Fail Logins Silently" is "No", but I do not get tokens when
logging in.  Neither is there any error message to indicate that the client
is even attempting to contact a server, nor any record in the server logs.

I've confirmed that toggling the "Obtain AFS tokens..." checkbox does
indeed toggle
HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider\LogonOptions.

I'm attempting standard AFS authentication, against krb5/fakeka.  I can
obtain tokens manually on the client without problems and that shows up in
the server logs as expected.

Cheers,
Stephen
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--------------050107080202080701030204-- --------------ms000807060302010008090705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxOTAyNTE0OVowIwYJKoZIhvcNAQkEMRYEFAr2GG1ySjx6 EPCBsBIspv091mN4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEApSdIl0FY7B0blwthS3ivwP0Mqfns WQKjmkHB3SZfxkU63n2Y+BIhjtbXa2mdHzf/0rl5MX3MPO7IYL6hlqMPoRWAHK0w/Khx83um 5aK2dzvXglmsjMZTGc++uxUcl48sB2C8LcRI8HUm8mNKYl3pCf9A4qB9OMY3GyrHY2mWgVmp D+dbfuKqgRHtplQLPS+PB+Znr6eL9rP7zzNNrumQ42NLxLkGAJkp6ynggrSejEbzA+fpRj44 PmhdEUYxfc1gXqk9be1GQkVQ+q8YIerAk8eI75+T6EWknOcsA5ZT9q6DolF9kKH4qJ1guqGf K9OLDgOedh0vouYtCZovVoVGFgAAAAAAAA== --------------ms000807060302010008090705-- From jaltman@columbia.edu Fri Mar 19 03:32:20 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 18 Mar 2004 22:32:20 -0500 Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: <405A6045.8010707@columbia.edu> References: <405A6045.8010707@columbia.edu> Message-ID: <405A69C4.20804@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms040802000006030402070106 Content-Type: multipart/alternative; boundary="------------030300000805000709050205" This is a multi-part message in MIME format. --------------030300000805000709050205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The reason that afslogon.dll is not being loaded is because of an oversite in the Installer. The installer is not adding "TransarcAFSDaemon" to the HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder and HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order keys. The service name needs to be appended to the Value named "Providers" in both keys. >> --------------030300000805000709050205 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The reason that afslogon.dll is not being loaded is because of an oversite in the Installer.
The installer is not adding "TransarcAFSDaemon" to the HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder and HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order keys.  The service name needs to be appended to the Value named "Providers" in both keys.


 

--------------030300000805000709050205-- --------------ms040802000006030402070106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxOTAzMzIyMFowIwYJKoZIhvcNAQkEMRYEFO8qiGSf+0+f YGleyPOsFAnIJ/aXMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAQ6ejAL1qIAnBZN35MObOySwF1tD1 jkwfwzJbBgFQ5bqq2UcTrQIYl0wEvOJ5x6mN9J0gMU225URADInJrwkKTa6NIBqDAYrZyIDw Y3u+46dLvf4vb1MSci0wbkR3hgCve1uYADr/b8r/fjoVYFPNeUkX3/2I6aXoV6PfxxPuCnus M6TKSZVtQOh0viOIyyyTEc8zn5AMrbIxtQT3IIeedgZLhreCCxFbD7fzZUHd32+u/UwL6q4F ZbSrfCgpxggMyJW1+sjsPkyaCJ+pH5YkLf5ku4ra7ghGPtlhg0WcUcGz6UFLljI//cgLb5zy fZRMynejUh9P0cZrH853Sc+DswAAAAAAAA== --------------ms040802000006030402070106-- From rra@stanford.edu Fri Mar 19 03:45:35 2004 From: rra@stanford.edu (Russ Allbery) Date: Thu, 18 Mar 2004 19:45:35 -0800 Subject: [OpenAFS] Retiring a partition In-Reply-To: <1079663516.25400.38.camel@sligo.mit.edu> (Tom Fitzgerald's message of "Thu, 18 Mar 2004 21:31:56 -0500") References: <20040318230926.37502.qmail@web61006.mail.yahoo.com> <1079663516.25400.38.camel@sligo.mit.edu> Message-ID: <87wu5h5wkg.fsf@windlord.stanford.edu> Tom Fitzgerald writes: > I'm attempting to retire a vice partition, but after moving all volumes > off it, it still contains two .vol files whose names correspond to > existing volumes that used to be in that partition but are now > elsewhere, and another hundred or so mystery files under the AFSIDat > directory. > vos listvldb confirms that no volumes of any kind are located there, and > bos salvage has no effect on the partition. This is normal. AFS over time tends to leave a bit of garbage behind, in the form of abandoned replication sites or data that it's just lost track of. We always find a bit of stuff like that after we evacuate a server. You can just delete it all when you have a good opportunity. -- Russ Allbery (rra@stanford.edu) From msantoro@pobox.com Fri Mar 19 04:56:29 2004 From: msantoro@pobox.com (Marc Santoro) Date: Thu, 18 Mar 2004 22:56:29 -0600 (CST) Subject: [OpenAFS] AFS CopyOnWrite problem In-Reply-To: <5C51DC2B8353AB4BA2CD04B34F2EE79C115F75@umr-umail1.umr.edu> References: <5C51DC2B8353AB4BA2CD04B34F2EE79C115F75@umr-umail1.umr.edu> Message-ID: I spent some time with 'strace' and judicious use of grep and the source and found a pseudo-resolution to the problem. Apparently, for some reason, AFS is trying to create new files over existing ones; I stuck a strace on all the fileserver processes, and grep'd for EEXIST, which was the errno=17 reported in the log. Every time I tried to create/remove/rename a file in the directory, I'd see something like this pop up in the strace output: open("/vicepa/AFSIDat/4/4+++U/+/+/T5++2kg", O_RDWR|O_CREAT|O_TRUNC|O_EXCL, 0) = -1 EEXIST (File exists). Upon moving all files that showed this error (there were only three), all symptoms went away. One of these files contained the contents of a PINE debug file; another was a binary file that looked like a directory (?). There seemed to be no data loss after moving the files, however. No problems appeared when I salvaged the partition. I don't know how this happened; maybe AFS thought those file names were good for new vnodes and tried to use them, and just punted when those file names turned out to be in use. So, crud left around, no longer referenced, but still occupying files? I don't know why the salvage operation wouldn't catch that, though . . . A kludge solution might be to check for the existance of a file before it is opened with O_EXCL, and move it out of the way if it is there. From shadow@dementia.org Fri Mar 19 05:09:21 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 19 Mar 2004 00:09:21 -0500 (EST) Subject: [OpenAFS] Retiring a partition In-Reply-To: <1079663516.25400.38.camel@sligo.mit.edu> References: <20040318230926.37502.qmail@web61006.mail.yahoo.com> <1079663516.25400.38.camel@sligo.mit.edu> Message-ID: On Thu, 18 Mar 2004, Tom Fitzgerald wrote: > Is there any way to determine what these files are still > being used for, if anything, and if not, why they got left > there? None of the "vos move"s or "vos remsite"s > reported any errors. remsite doesn't remove data; zap after remsite if you want it gone. From shadow@dementia.org Fri Mar 19 05:19:30 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 19 Mar 2004 00:19:30 -0500 (EST) Subject: [OpenAFS] AFS CopyOnWrite problem In-Reply-To: References: <5C51DC2B8353AB4BA2CD04B34F2EE79C115F75@umr-umail1.umr.edu> Message-ID: On Thu, 18 Mar 2004, Marc Santoro wrote: > I spent some time with 'strace' and judicious use of grep and the source > and found a pseudo-resolution to the problem. > > Apparently, for some reason, AFS is trying to create new files over > existing ones; I stuck a strace on all the fileserver processes, and > grep'd for EEXIST, which was the errno=17 reported in the log. Every time > I tried to create/remove/rename a file in the directory, I'd see something > like this pop up in the strace output: > > open("/vicepa/AFSIDat/4/4+++U/+/+/T5++2kg", O_RDWR|O_CREAT|O_TRUNC|O_EXCL, > 0) = -1 EEXIST (File exists). the logs of this list have references of such happening before. we fixed a few bugs that might cause the orphaned files to happen. > Upon moving all files that showed this error (there were only three), all > symptoms went away. One of these files contained the contents of a PINE > debug file; another was a binary file that looked like a directory (?). > There seemed to be no data loss after moving the files, however. No > problems appeared when I salvaged the partition. > > I don't know how this happened; maybe AFS thought those file names were > good for new vnodes and tried to use them, and just punted when those file > names turned out to be in use. So, crud left around, no longer referenced, > but still occupying files? I don't know why the salvage operation wouldn't > catch that, though . . . because a salvage wouldn't know they were there, since the volume didn't reference them. perhaps, though, it should be made to do something. > A kludge solution might be to check for the existance of a file before it > is opened with O_EXCL, and move it out of the way if it is there. well, technically it *is* an error condition, i don't think that's the right answer. changing salvager to deal is probably more "right" From hendrik.hoeth@cern.ch Fri Mar 19 12:57:55 2004 From: hendrik.hoeth@cern.ch (Hendrik Hoeth) Date: Fri, 19 Mar 2004 13:57:55 +0100 Subject: [OpenAFS] openssh-3.7.1, pam and no token after login In-Reply-To: <4056E6FC.6060302@njit.edu> References: <20031216024537.GB7479@mail.physik.uni-wuppertal.de> <2667060000.1071681540@mariner.pc.cs.cmu.edu> <4055D34D.7070103@njit.edu> <20040315161851.GC3621@hanuman.astro.su.se> <4056E6FC.6060302@njit.edu> Message-ID: <20040319125755.GA4570@mail.physik.uni-wuppertal.de> Thus spake Matthew E Hoskins - SAGE AFS (matt@njit.edu): > These solutions seem krb5 centric, we use kaserver on all our cells. Same problem here, still no fix. -- for (Int_t j = 0; j < 100; j++){ // ROOT Users Guide 3.10, p. 243 if (j < 100){ smallHisto->Fill(fTracks_fPx[j]); } } From kwc@citi.umich.edu Fri Mar 19 13:32:00 2004 From: kwc@citi.umich.edu (Kevin Coffman) Date: Fri, 19 Mar 2004 08:32:00 -0500 Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: <405A6045.8010707@columbia.edu> Message-ID: <007601c40db6$90b50d50$0501000a@coffman> This is a multi-part message in MIME format. ------=_NextPart_000_0077_01C40D8C.A7DF0550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jeff, I've had two reports (myself and someone else) about very slow behavior = in the OpenAFS dialog. (Obtain tokens, drive mappings) I didn't see this = with the 1.3.5299 version that I installed two days ago. This is with KfW = 2.6 beta 7 and beta 8 installed on WinXP machines. =20 K.C. -----Original Message----- From: openafs-info-admin@openafs.org = [mailto:openafs-info-admin@openafs.org] On Behalf Of Jeffrey Altman Sent: Thursday, March 18, 2004 9:52 PM To: Stephen Joyce Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] 1.3.6000 integrated logon? To be honest I have not even had time to look at afslogon.c yet. I just took a look at it and it scared me. There=20 is a mixture of calls to LocalAlloc() followed by calls to free() on the allocated memory which is sure to cause memory corruption. I do not know if it works or does not work. However, the=20 only changes to it since 1.2.10 are to the string used to identify the module when logging Events. Jeffrey Altman Stephen Joyce wrote: I'm testing the windows 1.3.6000 build--hoping it will solve several outstanding problems I've seen with OpenAFS 1.2.11 on windows. Can someone please confirm for me that obtaining tokens when logging = into Windows works on this build? I have checked "Obtain AFS tokens when logging into Windows", and made = sure that "Fail Logins Silently" is "No", but I do not get tokens when logging in. Neither is there any error message to indicate that the = client is even attempting to contact a server, nor any record in the server = logs. I've confirmed that toggling the "Obtain AFS tokens..." checkbox does indeed toggle HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider\= Log onOptions. I'm attempting standard AFS authentication, against krb5/fakeka. I can obtain tokens manually on the client without problems and that shows up = in the server logs as expected. Cheers, Stephen _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ------=_NextPart_000_0077_01C40D8C.A7DF0550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Jeff,
I've=20 had two reports (myself and someone else) about very = slow=20 behavior in the OpenAFS dialog.  (Obtain tokens, drive = mappings)  I=20 didn't see this with the 1.3.5299 version that I installed two days = ago. =20 This is with KfW 2.6 beta 7 and beta 8 installed on WinXP=20 machines.
 
K.C.
-----Original Message-----
From:=20 openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] = On=20 Behalf Of Jeffrey Altman
Sent: Thursday, March 18, 2004 = 9:52=20 PM
To: Stephen Joyce
Cc:=20 openafs-info@openafs.org
Subject: Re: [OpenAFS] 1.3.6000 = integrated=20 logon?

To be honest I have not even had time to = look at=20 afslogon.c
yet.  I just took a look at it and it scared = me. =20 There
is a mixture of calls to LocalAlloc() followed by calls = to
free()=20 on the allocated memory which is sure to cause = memory
corruption.

I=20 do not know if it works or does not work.  However, the
only = changes=20 to it since 1.2.10 are to the string used to
identify the module = when=20 logging Events.

Jeffrey Altman


Stephen Joyce wrote:
I'm =
testing the windows 1.3.6000 build--hoping it will solve several
outstanding problems I've seen with OpenAFS 1.2.11 on windows.

Can someone please confirm for me that obtaining tokens when logging =
into
Windows works on this build?

I have checked "Obtain AFS tokens when logging into Windows", and made =
sure
that "Fail Logins Silently" is "No", but I do not get tokens when
logging in.  Neither is there any error message to indicate that the =
client
is even attempting to contact a server, nor any record in the server =
logs.

I've confirmed that toggling the "Obtain AFS tokens..." checkbox does
indeed toggle
HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider\=
LogonOptions.

I'm attempting standard AFS authentication, against krb5/fakeka.  I can
obtain tokens manually on the client without problems and that shows up =
in
the server logs as expected.

Cheers,
Stephen
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://=
lists.openafs.org/mailman/listinfo/openafs-info
------=_NextPart_000_0077_01C40D8C.A7DF0550-- From stephen@physics.unc.edu Fri Mar 19 13:45:39 2004 From: stephen@physics.unc.edu (Stephen Joyce) Date: Fri, 19 Mar 2004 08:45:39 -0500 (EST) Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: <007601c40db6$90b50d50$0501000a@coffman> References: <007601c40db6$90b50d50$0501000a@coffman> Message-ID: FWIW, I've seen that very slow behavior too, but figured it was something I'm doing wrong... (the new versions, .5299 and .6000, also seem to consistently crash, with the question about sending a crash report to MS, every time I stop the service.) I see this on WinXPsp1 with only MS patches and OpenAFS installed. On Fri, 19 Mar 2004, Kevin Coffman wrote: > Jeff, > I've had two reports (myself and someone else) about very slow behavior in > the OpenAFS dialog. (Obtain tokens, drive mappings) I didn't see this with > the 1.3.5299 version that I installed two days ago. This is with KfW 2.6 > beta 7 and beta 8 installed on WinXP machines. > > K.C. > > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] > On Behalf Of Jeffrey Altman > Sent: Thursday, March 18, 2004 9:52 PM > To: Stephen Joyce > Cc: openafs-info@openafs.org > Subject: Re: [OpenAFS] 1.3.6000 integrated logon? > > > To be honest I have not even had time to look at afslogon.c > yet. I just took a look at it and it scared me. There > is a mixture of calls to LocalAlloc() followed by calls to > free() on the allocated memory which is sure to cause memory > corruption. > > I do not know if it works or does not work. However, the > only changes to it since 1.2.10 are to the string used to > identify the module when logging Events. > > Jeffrey Altman > > > Stephen Joyce wrote: > > > I'm testing the windows 1.3.6000 build--hoping it will solve several > > outstanding problems I've seen with OpenAFS 1.2.11 on windows. > > > > Can someone please confirm for me that obtaining tokens when logging into > > Windows works on this build? > > > > I have checked "Obtain AFS tokens when logging into Windows", and made sure > > that "Fail Logins Silently" is "No", but I do not get tokens when > > logging in. Neither is there any error message to indicate that the client > > is even attempting to contact a server, nor any record in the server logs. > > > > I've confirmed that toggling the "Obtain AFS tokens..." checkbox does > > indeed toggle > > HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider\Log > onOptions. > > > > I'm attempting standard AFS authentication, against krb5/fakeka. I can > > obtain tokens manually on the client without problems and that shows up in > > the server logs as expected. > > > > Cheers, > > Stephen > > _______________________________________________ > > OpenAFS-info mailing list > > OpenAFS-info@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-info > > > > From thomas@cs.wisc.edu Fri Mar 19 13:49:38 2004 From: thomas@cs.wisc.edu (David Thompson) Date: Fri, 19 Mar 2004 07:49:38 -0600 Subject: [OpenAFS] AFS CopyOnWrite problem In-Reply-To: Message from Derrick J Brashear of "Fri, 19 Mar 2004 00:19:30 EST." Message-ID: <200403191349.HAA14513@pongo.cs.wisc.edu> Derrick J Brashear wrote: > >> A kludge solution might be to check for the existance of a file before it >> is opened with O_EXCL, and move it out of the way if it is there. > >well, technically it *is* an error condition, i don't think that's the >right answer. changing salvager to deal is probably more "right" >From an operations standpoint, if the fileserver could deal with the problem (i.e. allow the file operation to succeed) at the point of detection (and maybe report to FileLog), that would be preferable to requiring admin intervention to fix it (by running the salvager). Maybe the salvager could still be required to provide a final disposition (attach/remove/whatever). Dave From joshua.johnson@ftlsys.com Fri Mar 19 13:57:03 2004 From: joshua.johnson@ftlsys.com (Joshua Johnson) Date: Fri, 19 Mar 2004 07:57:03 -0600 Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: References: <007601c40db6$90b50d50$0501000a@coffman> Message-ID: <200403190757.03684.joshua.johnson@ftlsys.com> I can ditto this for a new install I did yesterday, WinXP Pro, MS patches and OpenAFS. Loopback called "AFS". Exact Same behavior. If you want I can download the debuggers(MS & SysInternals) and try to get you something useful, if someone can give a little guidance. The Win2000 I did worked. The WinXP I can get tokens and see the share, but I have yet to see the cell in Explorer. Clicking the drive letter causes a 30-40 sec time delay and then I see no files or dirs. I'll keep looking for something I messed up. Best Regards, Joshua Johnson On Friday 19 March 2004 07:45 am, Stephen Joyce wrote: > FWIW, I've seen that very slow behavior too, but figured it was something > I'm doing wrong... (the new versions, .5299 and .6000, also seem to > consistently crash, with the question about sending a crash report to MS, > every time I stop the service.) I see this on WinXPsp1 with only MS > patches and OpenAFS installed. > > On Fri, 19 Mar 2004, Kevin Coffman wrote: > > Jeff, > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From jaltman@columbia.edu Fri Mar 19 14:41:33 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 19 Mar 2004 09:41:33 -0500 Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: References: <007601c40db6$90b50d50$0501000a@coffman> Message-ID: <405B069D.7010706@columbia.edu> This is a multi-part message in MIME format. --------------050004040001050208070502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen Joyce wrote: >FWIW, I've seen that very slow behavior too, but figured it was something >I'm doing wrong... (the new versions, .5299 and .6000, also seem to >consistently crash, with the question about sending a crash report to MS, >every time I stop the service.) I see this on WinXPsp1 with only MS >patches and OpenAFS installed. > > First, the crash is most likely in the new power management thread. The thread is not always shutting down before the service control thread finishes. I thought I had that fixed. As for the slow dialogs I am not sure. Is there any additional information you can provide? What do you mean by slow? Delays while entering text? Delays from the time the "OK" button is pressed until the tokens are obtained? One point of information is that in OpenAFS I discovered a very bad race condition between processes or threads on the same machine within ktc_SetToken() or ktc_GetToken() calls. Each call must perform two steps a pioctl() and an RPC. It is possible for two processes making calls at the same time to be stair stepped resulting in undesireable results. Therefore, I added a global mutex around the pairs of calls to ensure that only one thread/process is attempting to perform an operating at a time. This will introduce a very slight delay because the Obtain Tokens thread is competing with another thread within afscreds.exe which is also performing the pioctl()/RPC call combinations to obtain token status information. However, I cannot imagine the delay is all that great. Does a network trace reveal anything interesting? Jeffrey Altman --------------050004040001050208070502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Joyce wrote:
FWIW, I've seen that very slow behavior too, but figured it was something
I'm doing wrong... (the new versions, .5299 and .6000, also seem to
consistently crash, with the question about sending a crash report to MS,
every time I stop the service.)  I see this on WinXPsp1 with only MS
patches and OpenAFS installed.


First, the crash is most likely in the new power
management thread.  The thread is not always
shutting down before the service control thread
finishes.  I thought I had that fixed.


As for the slow dialogs I am not sure.  Is there
any additional information you can provide? 

What do you mean by slow?  Delays while entering
text?  Delays from the time the "OK" button is
pressed until the tokens are obtained? 

One point of information is that in OpenAFS I
discovered a very bad race condition between
processes or threads on the same machine within
ktc_SetToken() or ktc_GetToken() calls.  Each
call must perform two steps a pioctl() and an
RPC.  It is possible for two processes making
calls at the same time to be stair stepped
resulting in undesireable results.  Therefore,
I added a global mutex around the pairs of calls
to ensure that only one thread/process is
attempting to perform an operating at a time.
This will introduce a very slight delay because
the Obtain Tokens thread is competing with
another thread within afscreds.exe which is
also performing the pioctl()/RPC call combinations
to obtain token status information.  However,
I cannot imagine the delay is all that great.

Does a network trace reveal anything interesting?

Jeffrey Altman


--------------050004040001050208070502-- From antispamid2003@yahoo.com Fri Mar 19 14:43:18 2004 From: antispamid2003@yahoo.com (Pamela Goetz) Date: Fri, 19 Mar 2004 06:43:18 -0800 (PST) Subject: [OpenAFS] "Integrated Login Failed" under Windows 2000 In-Reply-To: <405A2D72.10805@columbia.edu> Message-ID: <20040319144318.83286.qmail@web61006.mail.yahoo.com> Jeffrey, thanks for your fast reply. It definitely explains why the Integraged Login fails since 'Administrator' is not a valid user name in my AFS cell. :) The problem is that based on your advice, I created an account (Power Users group) in my Windows 2000 workstation with the same exact username used to obtain tokens for AFS, but I get the same exact error when I login: AFS LOGON ERROR "Integrated Login Failed: " I click OK and then the "AFS Client Wizard" is displayed and reads: "The AFS Client service has not yet started". I click 'Next', but instead of starting the client and prompting me for username and password (for successful login as happens when I login as Administrator), I receive the following error: "The AFS Client service could not be started" Why can't the AFS Client service be started? Everything seems to be installed properly since it starts successfully when logged in as Administrator. Must a user have administrative priveleges in order to start the AFS Client? If not, what do I need to configure to make this work? I know about the AFS Client Configuration in Control Panel, but I couldn't find there anything directly related to my problem and I am afraid to start experimenting with the various options there beyond repair... Your help is very much appreciated! Thanks, Pam --- Jeffrey Altman wrote: > The username used to login to windows must match the username used to > obtain > tokens for AFS. Otherwise, the AFS Integrated Logon cannot work. > > Jeffrey Altman > > > Pamela Goetz wrote: > > >Whenever I restart my Windows 2000 PC (currently automatically login > >into Administrator account - as I am still in the process of > >installing/configuring it), It gives me the following error: > > > >AFS LOGON ERROR > >"Integrated Login Failed: " > > > >(the garbled text looks like an encypted password?) > > > >I click OK and then the "AFS Client Wizard" is displayed and reads: > >"The AFS Client service has not yet started". > > > >I then click "Next" and the client seems to have been started, > >prompting me for AFS cell, user name and password. The AFS cell edit > >box already contains the correct value. The user name edit, on the > >other hand, contains 'Administrator' - which is of course incorrect. > I > >type in my AFS username and password, click 'Next, and everything > works > >fine (I get the message: "The AFS Client is ready for use". > > > >Now... while it is very nice that I can make my AFS client on > Windows > >2000 work, it is very inconvenient to always have to type the > username > >and password whenever I logon. So, my question is: > > > >How do make the AFS client service start up automatically and > >automatically logon using the username & password that work so > >perfectly when I enter them manually? > > > >I am using AFS Version 1.2.10 > > > > > >Thanks, > >Pam __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com From jaltman@columbia.edu Fri Mar 19 14:44:53 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 19 Mar 2004 09:44:53 -0500 Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: <200403190757.03684.joshua.johnson@ftlsys.com> References: <007601c40db6$90b50d50$0501000a@coffman> <200403190757.03684.joshua.johnson@ftlsys.com> Message-ID: <405B0765.3070605@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms000607090101090704010603 Content-Type: multipart/alternative; boundary="------------010801060308050806040708" This is a multi-part message in MIME format. --------------010801060308050806040708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Joshua Johnson wrote: >The Win2000 I did worked. The WinXP I can get tokens and see the share, but I >have yet to see the cell in Explorer. Clicking the drive letter causes a >30-40 sec time delay and then I see no files or dirs. I'll keep looking for >something I messed up. > >Best Regards, > > >Joshua Johnson > What does "nbtstat -n" report? What does "net use" report? What is listed in the %WINDIR%\TEMP\afsd_init.log and %WINDIR%\TEMP\afsd.log files? Jeffrey Altman --------------010801060308050806040708 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Joshua Johnson wrote:
The Win2000 I did worked.  The WinXP I can get tokens and see the share, but I 
have yet to see the cell in Explorer.  Clicking the drive letter causes a 
30-40 sec time delay and then I see no files or dirs.  I'll keep looking for 
something I messed up.

Best Regards,


Joshua Johnson

What does "nbtstat -n" report?

What does "net use" report?

What is listed in the %WINDIR%\TEMP\afsd_init.log and %WINDIR%\TEMP\afsd.log files?

Jeffrey Altman

--------------010801060308050806040708-- --------------ms000607090101090704010603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxOTE0NDQ1M1owIwYJKoZIhvcNAQkEMRYEFH3M2IrSHoi2 X6DO00R7wcEKrTDxMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAIuOIIg93bwTKPsgt9yKFMnXYXNMo E7bGWpdmuR2vutKSbSqs0QZ5gL0gQygqm6t02jO3Y9LAZeMcpLmsoEuz6Ef0S5VnGR8DeOjc C3WPUT0CL6CJCXVuL/8ycPS78ny5HnomWEmHgg4TDDvPdMgxydYXDYYmPsMbGi8Fc2mqtim0 4dRB4wJI50g7n6Id4EdfPP4wCiXAZeXV9joUEP0En8YWoRPzmwQKLAVM0Yji8rm4g6eVk0Fg YclZzfW+AT2DAiuikJgN9gaeLs/ZOg3aywc8B0EEDQcUKuAjQyYBycU7nU2VB30dgX5ZGMGP 9pq1asOMQigOape6w6IkH5XZZgAAAAAAAA== --------------ms000607090101090704010603-- From jaltman@columbia.edu Fri Mar 19 14:51:58 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 19 Mar 2004 09:51:58 -0500 Subject: [OpenAFS] "Integrated Login Failed" under Windows 2000 In-Reply-To: <20040319144318.83286.qmail@web61006.mail.yahoo.com> References: <20040319144318.83286.qmail@web61006.mail.yahoo.com> Message-ID: <405B090E.3020507@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms090205010504080400040709 Content-Type: multipart/alternative; boundary="------------070002030704040209080907" This is a multi-part message in MIME format. --------------070002030704040209080907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit You can't start the service from a non-administrator account with the 1.2.xx builds. This was fixed in the 1.3.50 and higher builds. Do the following. Install the 1.3.60 build that was announced yesterday and append the service "TransarcAFSDaemon" to the list specified in the registry value: Key: HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order Value: ProviderOrder [This step was left out of the installer. A new installer will replace the existing one in a couple of days once all of the other reports of trouble get sorted out.] If you are still having trouble reply to this e-mail. Jeffrey Altman Pamela Goetz wrote: >Jeffrey, thanks for your fast reply. It definitely explains why the >Integraged Login fails since 'Administrator' is not a valid user name >in my AFS cell. :) > >The problem is that based on your advice, I created an account (Power >Users group) in my Windows 2000 workstation with the same exact >username used to obtain tokens for AFS, but I get the same exact error >when I login: > >AFS LOGON ERROR >"Integrated Login Failed: " > >I click OK and then the "AFS Client Wizard" is displayed and reads: >"The AFS Client service has not yet started". > >I click 'Next', but instead of starting the client and prompting me for >username and password (for successful login as happens when I login as >Administrator), I receive the following error: > >"The AFS Client service could not be started" > > >Why can't the AFS Client service be started? Everything seems to be >installed properly since it starts successfully when logged in as >Administrator. Must a user have administrative priveleges in order to >start the AFS Client? > >If not, what do I need to configure to make this work? I know about the >AFS Client Configuration in Control Panel, but I couldn't find there >anything directly related to my problem and I am afraid to start >experimenting with the various options there beyond repair... > > >Your help is very much appreciated! > >Thanks, >Pam > > > >--- Jeffrey Altman wrote: > >>The username used to login to windows must match the username used to >>obtain >>tokens for AFS. Otherwise, the AFS Integrated Logon cannot work. >> >>Jeffrey Altman >> >> >>Pamela Goetz wrote: >> >> >>>Whenever I restart my Windows 2000 PC (currently automatically login >>>into Administrator account - as I am still in the process of >>>installing/configuring it), It gives me the following error: >>> >>>AFS LOGON ERROR >>>"Integrated Login Failed: " >>> >>>(the garbled text looks like an encypted password?) >>> >>>I click OK and then the "AFS Client Wizard" is displayed and reads: >>>"The AFS Client service has not yet started". >>> >>>I then click "Next" and the client seems to have been started, >>>prompting me for AFS cell, user name and password. The AFS cell edit >>>box already contains the correct value. The user name edit, on the >>>other hand, contains 'Administrator' - which is of course incorrect. >>> >>I >> >>>type in my AFS username and password, click 'Next, and everything >>> >>works >> >>>fine (I get the message: "The AFS Client is ready for use". >>> >>>Now... while it is very nice that I can make my AFS client on >>> >>Windows >> >>>2000 work, it is very inconvenient to always have to type the >>> >>username >> >>>and password whenever I logon. So, my question is: >>> >>>How do make the AFS client service start up automatically and >>>automatically logon using the username & password that work so >>>perfectly when I enter them manually? >>> >>>I am using AFS Version 1.2.10 >>> >>> >>>Thanks, >>>Pam >>> > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - More reliable, more storage, less spam >http://mail.yahoo.com > --------------070002030704040209080907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit You can't start the service from a non-administrator account
with the 1.2.xx builds.  This was fixed in the 1.3.50 and higher builds.

Do the following.  Install the 1.3.60 build that was announced
yesterday and append the service "TransarcAFSDaemon" to the
list specified in the registry value:

    Key:  HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
    Value:  ProviderOrder

[This step was left out of the installer.  A new installer will replace the
existing one in a couple of days once all of the other reports of trouble
get sorted out.]

If you are still having trouble reply to this e-mail.

Jeffrey Altman


Pamela Goetz wrote:
Jeffrey, thanks for your fast reply. It definitely explains why the
Integraged Login fails since 'Administrator' is not a valid user name
in my AFS cell. :)

The problem is that based on your advice, I created an account (Power
Users group) in my Windows 2000 workstation with the same exact
username used to obtain tokens for AFS, but I get the same exact error
when I login:

AFS LOGON ERROR
"Integrated Login Failed: <some garbled text>"

I click OK and then the "AFS Client Wizard" is displayed and reads:
"The AFS Client service has not yet started".

I click 'Next', but instead of starting the client and prompting me for
username and password (for successful login as happens when I login as
Administrator), I receive the following error:

"The AFS Client service could not be started"


Why can't the AFS Client service be started? Everything seems to be
installed properly since it starts successfully when logged in as
Administrator. Must a user have administrative priveleges in order to
start the AFS Client?

If not, what do I need to configure to make this work? I know about the
AFS Client Configuration in Control Panel, but I couldn't find there
anything directly related to my problem and I am afraid to start
experimenting with the various options there beyond repair...


Your help is very much appreciated!

Thanks,
Pam



--- Jeffrey Altman <jaltman@columbia.edu> wrote:
The username used to login to windows must match the username used to
obtain
tokens for AFS.  Otherwise, the AFS Integrated Logon cannot work.

Jeffrey Altman


Pamela Goetz wrote:

Whenever I restart my Windows 2000 PC (currently automatically login
into Administrator account - as I am still in the process of
installing/configuring it), It gives me the following error:

AFS LOGON ERROR
"Integrated Login Failed: <some garbled text>"

(the garbled text looks like an encypted password?)

I click OK and then the "AFS Client Wizard" is displayed and reads:
"The  AFS Client service has not yet started".

I then click "Next" and the client seems to have been started,
prompting me for AFS cell, user name and password. The AFS cell edit
box already contains the correct value. The user name edit, on the
other hand, contains 'Administrator' - which is of course incorrect.
I
type in my AFS username and password, click 'Next, and everything
works
fine (I get the message: "The AFS Client is ready for use".

Now... while it is very nice that I can make my AFS client on
Windows
2000 work, it is very inconvenient to always have to type the
username
and password whenever I logon. So, my question is:

How do make the AFS client service start up automatically and
automatically logon using the username & password that work so
perfectly when I enter them manually?

I am using AFS Version 1.2.10


Thanks,
Pam 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
--------------070002030704040209080907-- --------------ms090205010504080400040709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxOTE0NTE1OFowIwYJKoZIhvcNAQkEMRYEFAG9AqbdY7in zrpVXP702NtqroN5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAlRJwXnTxCEi67GMT6ISinGhcgk7a vH3wRBuvdN+dWZhADkAOsRGJCNI4ljnqA1roHax2BRFCH/idlf3TXk1AzBveDFBZukPiznFc 7e0moAOvr2LmDFDJIIQpJSQv4o/F61Wc9TnfJxtampm8sBUGlZk+mKY2QVOKCTm9OlzAicfp 7mCnTXzpcDmsFVdqNoRSxU21ZcRjWomYsrcLK6tWOOlwQttbC0GMATk0/rHYcKBNtxuqX4Nj to1XWxmrMa3rE9IZotD0/yalNYrqwYEns0SwInh251kQJeG7HrO3ofgnE/9OQo0vsbGaPEok I7rZgJZm2CHJrNHzMdbuUviMcAAAAAAAAA== --------------ms090205010504080400040709-- From kwc@citi.umich.edu Fri Mar 19 15:43:58 2004 From: kwc@citi.umich.edu (Kevin Coffman) Date: Fri, 19 Mar 2004 10:43:58 -0500 Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: <405B069D.7010706@columbia.edu> Message-ID: <000d01c40dc9$14e0a230$0501000a@coffman> This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C40D9F.2C0A9A30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I'm at home today, so I can't do much to help diagnosing. The problem I = saw was a 30-60 delay after double-clicking the tray icon before the dialog appeared. Switching between tabs from tokens to drive mappings takes = 30-60 seconds or more. Redrawing the dialog box has a similar delay. I = didn't do a network trace, but I did look at CPU. afscreds is using CPU, but it's = not like it is pegged (2 to 9% usage). -----Original Message----- From: Jeffrey Altman [mailto:jaltman@columbia.edu]=20 Sent: Friday, March 19, 2004 9:42 AM To: Stephen Joyce Cc: Kevin Coffman; openafs-info@openafs.org Subject: Re: [OpenAFS] 1.3.6000 integrated logon? Stephen Joyce wrote: FWIW, I've seen that very slow behavior too, but figured it was = something I'm doing wrong... (the new versions, .5299 and .6000, also seem to consistently crash, with the question about sending a crash report to = MS, every time I stop the service.) I see this on WinXPsp1 with only MS patches and OpenAFS installed. First, the crash is most likely in the new power management thread. The thread is not always=20 shutting down before the service control thread finishes. I thought I had that fixed. As for the slow dialogs I am not sure. Is there any additional information you can provide? =20 What do you mean by slow? Delays while entering text? Delays from the time the "OK" button is pressed until the tokens are obtained? =20 One point of information is that in OpenAFS I=20 discovered a very bad race condition between=20 processes or threads on the same machine within ktc_SetToken() or ktc_GetToken() calls. Each call must perform two steps a pioctl() and an RPC. It is possible for two processes making calls at the same time to be stair stepped=20 resulting in undesireable results. Therefore, I added a global mutex around the pairs of calls to ensure that only one thread/process is=20 attempting to perform an operating at a time. This will introduce a very slight delay because the Obtain Tokens thread is competing with=20 another thread within afscreds.exe which is also performing the pioctl()/RPC call combinations to obtain token status information. However,=20 I cannot imagine the delay is all that great. Does a network trace reveal anything interesting? Jeffrey Altman ------=_NextPart_000_000E_01C40D9F.2C0A9A30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
I'm at=20 home today, so I can't do much to help diagnosing.  The problem I = saw was a=20 30-60 delay after double-clicking the tray icon before the dialog=20 appeared.  Switching between tabs from tokens to drive mappings = takes 30-60=20 seconds or more.  Redrawing the dialog box has a similar = delay.  I=20 didn't do a network trace, but I did look at CPU.  = afscreds is=20 using CPU, but it's not like it is pegged (2 to 9% = usage).
-----Original Message-----
From: = Jeffrey Altman=20 [mailto:jaltman@columbia.edu]
Sent: Friday, March 19, 2004 = 9:42=20 AM
To: Stephen Joyce
Cc: Kevin Coffman;=20 openafs-info@openafs.org
Subject: Re: [OpenAFS] 1.3.6000 = integrated=20 logon?

Stephen = Joyce=20 wrote:
FWIW, =
I've seen that very slow behavior too, but figured it was something
I'm doing wrong... (the new versions, .5299 and .6000, also seem to
consistently crash, with the question about sending a crash report to =
MS,
every time I stop the service.)  I see this on WinXPsp1 with only MS
patches and OpenAFS installed.


First, the crash is most likely in the new = power
management thread.  The thread is not always =
shutting down=20 before the service control thread
finishes.  I thought I had = that=20 fixed.


As for the slow dialogs I am not sure.  Is = there
any=20 additional information you can provide? 

What do you mean = by=20 slow?  Delays while entering
text?  Delays from the time = the "OK"=20 button is
pressed until the tokens are obtained? 

One = point of=20 information is that in OpenAFS I
discovered a very bad race = condition=20 between
processes or threads on the same machine = within
ktc_SetToken()=20 or ktc_GetToken() calls.  Each
call must perform two steps a = pioctl()=20 and an
RPC.  It is possible for two processes making
calls = at the=20 same time to be stair stepped
resulting in undesireable = results. =20 Therefore,
I added a global mutex around the pairs of calls
to = ensure=20 that only one thread/process is
attempting to perform an operating = at a=20 time.
This will introduce a very slight delay because
the Obtain = Tokens=20 thread is competing with
another thread within afscreds.exe which=20 is
also performing the pioctl()/RPC call combinations
to obtain = token=20 status information.  However,
I cannot imagine the delay is = all that=20 great.

Does a network trace reveal anything = interesting?

Jeffrey=20 Altman


------=_NextPart_000_000E_01C40D9F.2C0A9A30-- From jaltman@columbia.edu Fri Mar 19 16:02:58 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 19 Mar 2004 11:02:58 -0500 Subject: [OpenAFS] 1.3.6000 integrated logon? In-Reply-To: <000d01c40dc9$14e0a230$0501000a@coffman> References: <000d01c40dc9$14e0a230$0501000a@coffman> Message-ID: <405B19B2.7070508@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms000403030403080802040705 Content-Type: multipart/alternative; boundary="------------060208060004080009050600" This is a multi-part message in MIME format. --------------060208060004080009050600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kevin Coffman wrote: > I'm at home today, so I can't do much to help diagnosing. The problem > I saw was a 30-60 delay after double-clicking the tray icon before the > dialog appeared. Switching between tabs from tokens to drive mappings > takes 30-60 seconds or more. Redrawing the dialog box has a similar > delay. I didn't do a network trace, but I did look at CPU. afscreds > is using CPU, but it's not like it is pegged (2 to 9% usage). At least now the description of the problem is starting to come out. That sounds like there might be a conflict between the SMB names used for the mount points and those for the network shares (left over from the previous install) Does the problem go away if you change the "NetbiosName" value to read "%COMPUTER-NAME%-AFS" instead of "AFS"? If so, remove all of the shares, reboot, switch back to "AFS", stop/start the afs client service, and then create your shares. Jeffrey Altman --------------060208060004080009050600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kevin Coffman wrote:
Message
I'm at home today, so I can't do much to help diagnosing.  The problem I saw was a 30-60 delay after double-clicking the tray icon before the dialog appeared.  Switching between tabs from tokens to drive mappings takes 30-60 seconds or more.  Redrawing the dialog box has a similar delay.  I didn't do a network trace, but I did look at CPU.  afscreds is using CPU, but it's not like it is pegged (2 to 9% usage).
At least now the description of the problem is starting to come out. 
That sounds like there might be a conflict between the SMB names used for the mount points and those for the network shares (left over from the previous install)

Does the problem go away if you change the "NetbiosName" value to read  "%COMPUTER-NAME%-AFS" instead of "AFS"?

If so, remove all of the shares, reboot, switch back to "AFS", stop/start the afs client service, and then create your shares. 

Jeffrey Altman

--------------060208060004080009050600-- --------------ms000403030403080802040705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxOTE2MDI1OFowIwYJKoZIhvcNAQkEMRYEFP6IccQoqfcA EzcBdjm6vb/x80IbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAmtPDvt2M8O1Xayltlq0dqJsfQuKO OpOxAS7qu0F80khcLkZdXzPlDYUUya9jdPRX4xJNVEsZFePgVtqzGWJgYpuBWTm7TmtUN3/h SuaYx6jdgUc2xpmjx37em+mmxO2lpJd2iIzLbe4GigoVM+vflVFD5Bgc7tb+BIe8wupEREP6 inDHUnS/icO5CMhl9VCIpai0SRYv4NUahfwXf9ALqasjwhMtW4/PtTPx0b00PRGQ8mV13PKB geUWJ1KjhPguSUXMn08t24KhJWL0g5fPfz2WENWr0z/ix33HJykM9EfbTXclrhnzEy9E8ptW CzSf8RgOz8o3iAljy66OD+VcAwAAAAAAAA== --------------ms000403030403080802040705-- From David.Bear@asu.edu Fri Mar 19 16:57:20 2004 From: David.Bear@asu.edu (David Bear) Date: Fri, 19 Mar 2004 09:57:20 -0700 Subject: [OpenAFS] "Integrated Login Failed" under Windows 2000 In-Reply-To: <405B090E.3020507@columbia.edu> References: <20040319144318.83286.qmail@web61006.mail.yahoo.com> <405B090E.3020507@columbia.edu> Message-ID: <20040319165720.GE6050@asu.edu> On Fri, Mar 19, 2004 at 09:51:58AM -0500, Jeffrey Altman wrote: > You can't start the service from a non-administrator account > with the 1.2.xx builds. This was fixed in the 1.3.50 and higher builds. well. I think you can but NOT from the gui. Using command line net start "IBM AFS Client" works for me.. since we do it all the time when afs becomes to finicky. But we're still at 1.2.8 and 1.2.10 versions. > > Do the following. Install the 1.3.60 build that was announced > yesterday and append the service "TransarcAFSDaemon" to the > list specified in the registry value: > > Key: HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order > Value: ProviderOrder This is really good news. Sorry to be slow on the uptake but where is the 1.3.60 build for windows found? I didn't see it in the download section on the web page last I checked.. -- David Bear phone: 480-965-8257 fax: 480-965-9189 College of Public Programs/ASU Wilson Hall 232 Tempe, AZ 85287-0803 "Beware the IP portfolio, everyone will be suspect of trespassing" From openafs@butchwax.com Fri Mar 19 04:07:03 2004 From: openafs@butchwax.com (John Morris) Date: 18 Mar 2004 22:07:03 -0600 Subject: [OpenAFS] no quorum elected In-Reply-To: <2014330000.1079657086@minbar.fac.cs.cmu.edu> References: <2014330000.1079657086@minbar.fac.cs.cmu.edu> Message-ID: D'oh! That would be my problem! Thanks for the tip. John Jeffrey Hutzelman writes: > On Thursday, March 18, 2004 17:42:51 -0600 John Morris > wrote: > > > Hi! > > > > My openafs system has this problem: > > > > # vos move root.mail kug /vicepa nixon /vicepa > > Could not lock entry for volume 536871065 > > u: no quorum elected > > > > I guessed that it was the 2004-01-10 bug, so I've been upgrading my > > servers. > > > > There are three file servers; I've upgraded two already from 1.2.9 to > > 1.2.11. The third still runs 1.2.9, and it's going to be scary > > upgrading it 'cause it's physically about 200 miles away from me, and > > the way the first two went, it's a coin-flip whether I'll need to get > > on the console. > > > > Anyway, I figured that getting 2 of 3 would give me a quorum, but the > > machines still have the same problem. Does this bug affect the whole > > system if only one machine is running the old version, or do I have a > > different problem? > > The bug prevents establishment of quorum if the machine that should > become coordinator (normally the one with the numerically-lowest IP > address) is not running the new version. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- John Morris +1-512-480-0200x1002 From jaltman@columbia.edu Fri Mar 19 17:10:29 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 19 Mar 2004 12:10:29 -0500 Subject: [OpenAFS] "Integrated Login Failed" under Windows 2000 In-Reply-To: <20040319165720.GE6050@asu.edu> References: <20040319144318.83286.qmail@web61006.mail.yahoo.com> <405B090E.3020507@columbia.edu> <20040319165720.GE6050@asu.edu> Message-ID: <405B2985.20503@columbia.edu> This is a multi-part message in MIME format. --------------030701060105040301050803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David Bear wrote: >On Fri, Mar 19, 2004 at 09:51:58AM -0500, Jeffrey Altman wrote: > >>You can't start the service from a non-administrator account >>with the 1.2.xx builds. This was fixed in the 1.3.50 and higher builds. >> > >well. I think you can but NOT from the gui. Using command line > >net start "IBM AFS Client" > >works for me.. since we do it all the time when afs becomes to >finicky. But we're still at 1.2.8 and 1.2.10 versions. > yes, this will work assuming the users have the necessary bits. >>Do the following. Install the 1.3.60 build that was announced >>yesterday and append the service "TransarcAFSDaemon" to the >>list specified in the registry value: >> >> Key: HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order >> Value: ProviderOrder >> > >This is really good news. Sorry to be slow on the uptake but where is >the 1.3.60 build for windows found? I didn't see it in the download >section on the web page last I checked.. > Please subscribe to openafs-announce if you do not already. Or read the home page of http://www.openafs.org and follow the links to either the announcement http://lists.openafs.org/pipermail/openafs-announce/2004/000071.html or the release http://www.openafs.org/release/openafs-1.3.60.html or latest release http://www.openafs.org/release/latest.html or latest unstable http://www.openafs.org/release/latest-unstable.html Jeffrey Altman --------------030701060105040301050803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit David Bear wrote:
On Fri, Mar 19, 2004 at 09:51:58AM -0500, Jeffrey Altman wrote:
You can't start the service from a non-administrator account
with the 1.2.xx builds.  This was fixed in the 1.3.50 and higher builds.

well. I think you can but NOT from the gui. Using command line

net start "IBM AFS Client"

works for me.. since we do it all the time when afs becomes to
finicky.  But we're still at 1.2.8 and 1.2.10 versions. 

yes, this will work assuming the users have the
necessary bits.
Do the following.  Install the 1.3.60 build that was announced
yesterday and append the service "TransarcAFSDaemon" to the
list specified in the registry value:

   Key:  HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
   Value:  ProviderOrder

This is really good news.  Sorry to be slow on the uptake but where is
the 1.3.60 build for windows found?  I didn't see it in the download
section on the web page last I checked..
Please subscribe to openafs-announce if you do not already.

Or read the home page of http://www.openafs.org and follow
the links to either the announcement

  http://lists.openafs.org/pipermail/openafs-announce/2004/000071.html

or the release

  http://www.openafs.org/release/openafs-1.3.60.html

or latest release

  http://www.openafs.org/release/latest.html

or latest unstable

  http://www.openafs.org/release/latest-unstable.html

Jeffrey Altman


--------------030701060105040301050803-- From jnurmi-openafs-info@qwe.cc Fri Mar 19 17:40:28 2004 From: jnurmi-openafs-info@qwe.cc (J. D. Nurmi) Date: Fri, 19 Mar 2004 12:40:28 -0500 Subject: [OpenAFS] Kerberos troubles... Message-ID: <1079718027.18012.37.camel@qwe.cc> Ok, out of boredom, I decided to setup AFS at home, and I'm running into a bit of issue with kerberos, and I cant seem to figure out where I went wrong versus our production machines in the office... General details: AFS Cell: qwe.cc Kerberos: QWE.CC One of the issues is that I'm using DNS for kerberos resolution, but I dont control the in-arpa records, so I have to hack around a bit w/ the default_realm, etc, and I suspect this is part of the problem. Anywho, when I try to aklog, I get: aklog: Couldn't get qwe.cc AFS tickets: aklog: Server not found in Kerberos database while getting AFS ticket Which in itself is usually an idic. of a kerberos problem... Which it is, as, when examined in the logs, you see: Mar 19 12:14:43 michelangelo.qwe.cc krb5kdc[853](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 69.162.159.65: UNKNOWN_SERVER: authtime 1079716481, jnurmi@QWE.CC for krbtgt/CC@QWE.CC, Server not found in Kerberos database If I add a krbtgt/CC principal (and ktab it) it instead balks on DNS, looking for _kerberos._tcp.CC which, while I could do even _more_ hacks to make it work, that just seems dirty dirty dirty. Any clue why AFS wants to talk to CC instead of QWE.CC, and further, how to fix it? Thanks in advance, James Nurmi From jaltman@columbia.edu Fri Mar 19 18:56:39 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 19 Mar 2004 13:56:39 -0500 Subject: [OpenAFS] 1.3.6000 delays - are they caused by DNS? In-Reply-To: <405B2985.20503@columbia.edu> References: <20040319144318.83286.qmail@web61006.mail.yahoo.com> <405B090E.3020507@columbia.edu> <20040319165720.GE6050@asu.edu> <405B2985.20503@columbia.edu> Message-ID: <405B4267.3040109@columbia.edu> for those experiencing delays with afscreds.exe. do the delays go away if you set? HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters UseDNS (DWORD) = 0x00 and then restart the AFS Client Service? Jeffrey Altman From dwb7@ccmr.cornell.edu Fri Mar 19 19:48:10 2004 From: dwb7@ccmr.cornell.edu (David Botsch) Date: Fri, 19 Mar 2004 14:48:10 -0500 Subject: [OpenAFS] afsdb refresh interval Message-ID: <20040319144810.D12630@ccmr.cornell.edu> If I were to move database servers and did this by updating the afsdb records in dns, how long would it take the clients to find the new servers (assuming cell db servers not in CellServDB)? Do the clients only check dns on the first access to the cell, on every transaction, every x transactions, every x minutes/hours? Thnx. -- ******************************** David William Botsch Consultant/Advisor II CCMR Computing Facility dwb7@ccmr.cornell.edu ******************************** From deengert@anl.gov Fri Mar 19 20:07:16 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Fri, 19 Mar 2004 14:07:16 -0600 Subject: [OpenAFS] Kerberos troubles... References: <1079718027.18012.37.camel@qwe.cc> Message-ID: <405B52F4.C8605F1C@anl.gov> "J. D. Nurmi" wrote: > > Ok, out of boredom, I decided to setup AFS at home, and I'm running into > a bit of issue with kerberos, and I cant seem to figure out where I went > wrong versus our production machines in the office... > > General details: > AFS Cell: qwe.cc > Kerberos: QWE.CC > > One of the issues is that I'm using DNS for kerberos resolution, but I > dont control the in-arpa records, so I have to hack around a bit w/ the > default_realm, etc, and I suspect this is part of the problem. > > Anywho, when I try to aklog, I get: > aklog: Couldn't get qwe.cc AFS tickets: > aklog: Server not found in Kerberos database while getting AFS ticket > > Which in itself is usually an idic. of a kerberos problem... Which it > is, as, when examined in the logs, you see: > > Mar 19 12:14:43 michelangelo.qwe.cc krb5kdc[853](info): TGS_REQ (7 > etypes {18 17 16 23 1 3 2}) 69.162.159.65: UNKNOWN_SERVER: authtime > 1079716481, jnurmi@QWE.CC for krbtgt/CC@QWE.CC, Server not found in > Kerberos database Its trying to do cross realm, and is trying to walk the DNS tree from QWE.CC to CC. It thinks your server is in some other realm other then QWE.CC > > If I add a krbtgt/CC principal (and ktab it) it instead balks on DNS, Don't do that unless you have some cross realm trust with CC > looking for _kerberos._tcp.CC which, while I could do even _more_ hacks > to make it work, that just seems dirty dirty dirty. > > Any clue why AFS wants to talk to CC instead of QWE.CC, and further, how > to fix it? > > Thanks in advance, > > James Nurmi > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rmdyer@uncc.edu Fri Mar 19 20:57:01 2004 From: rmdyer@uncc.edu (Rodney M Dyer) Date: Fri, 19 Mar 2004 15:57:01 -0500 Subject: [OpenAFS] 1.3.6000 delays - are they caused by DNS? In-Reply-To: <405B4267.3040109@columbia.edu> References: <20040319144318.83286.qmail@web61006.mail.yahoo.com> <405B090E.3020507@columbia.edu> <20040319165720.GE6050@asu.edu> <405B2985.20503@columbia.edu> <405B4267.3040109@columbia.edu> Message-ID: <6.0.0.22.0.20040319153352.01daf9f0@email.uncc.edu> Jeffrey, I can confirm the problems others are having. 1. Running "afs_config.exe" then traversing from the "General" tab to the "Drive Letters" tab takes about 10 seconds. 2. Runing the "afscreds.exe" then choosing the "Drive Letters" tab also causes a pause of about 10 seconds. 3. Stopping the AFS service sometimes causes a crash, aka...send mail to Microsoft, etc. 4. Changing the UseDNS value has no effect. Here's a copy of my "c:\winnt\temp\afsd_init.log"... http://www.coe.uncc.edu/~rmdyer/OpenAFSforWindows-1-3-6000_afsd_init_log1.txt Rodney At 01:56 PM 3/19/2004, Jeffrey Altman wrote: >for those experiencing delays with afscreds.exe. >do the delays go away if you set? > > HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters > UseDNS (DWORD) = 0x00 > >and then restart the AFS Client Service? > >Jeffrey Altman > > >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info From Renata Maria Dart Fri Mar 19 21:13:27 2004 From: Renata Maria Dart (Renata Maria Dart) Date: Fri, 19 Mar 2004 13:13:27 -0800 (PST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 Message-ID: <0HUU006OVDMFYQ@mailbox.slac.stanford.edu> We have been happily running OpenAFS fileservers uneventfully for a number of months until one of them, afs09, crashed in January. Our fileservers are Sun 280R systems each with 400gb of storage, running solaris 9 and a mix of OpenAFS 1.2.9 and 1.2.10, and now 1.2.11 on the problem fileserver. Since the crash, we have had a number of further disturbing problems with that same fileserver: 1. Afs09 crashed on January 22. It was running 1.2.9 at that time. I have the corefile.fs from that crash but I have not been able to figure out the cause. After it restarted it was then running 1.2.10. I have the core and the fileserver in case someone has time to look at it. 2. After that crash, a number of our users found that they had an unremovable gnome lock file, /.gconfd/lock/ior. This prevented them from starting up a gnome session. A bos salvage of the user's home directory volume fixed the problem (despite the fact that salvage already ran as a result of the crash) and left the following in SalvageLog: 03/19/2004 09:26:46 dir vnode 157: ./.gconfd/lock/ior (vnode 230): unique change d from 1519582 to 1519806 03/19/2004 09:26:46 dir vnode 157: ./.gconfd/lock/ior already claimed by directo ry vnode 1 (vnode 230, unique 1519582) -- deleted 03/19/2004 09:26:46 dir vnode 845: ./.gconf/%gconf-xml-backend.lock/ior (vnode 1 198): unique changed from 1519585 to 1519736 03/19/2004 09:26:46 dir vnode 845: ./.gconf/%gconf-xml-backend.lock/ior already claimed by directory vnode 571 (vnode 1198, unique 1519585) -- deleted When I look at a "normal" .gconfd directory today I see a hard link: renata@afs09 $ 9:46 cd .gconfd/lock renata@afs09 $ 9:46 ls -lAi total 0 694881134 -rwx------ 2 ljm sf 0 Mar 19 09:31 .__afsE87F* 694881134 -rwx------ 2 ljm sf 0 Mar 19 09:31 ior* Is this part of the problem? 3. Last week we had a meltdown on this fileserver....the idle entries in the output from the meltdown script dropped to 2 while the wproc jumped up to the 7000s. I could not find any one culprit with snoop and eventually tried to restart the system. After 40 minutes, when it didn't restart, I ended up killing the fileserver and restarting it. I unfortunately did not get any showproc output or a fileserver core...I will try to get that if we experience another one. There was nothing in the FileLog around the time of the meltdown. 4. Again there were .gconf lock problems following this incident. While repairing some of the .gconf lock problems, one our bos salvages refused to complete. It went on for 2 pages of bos: waiting for salvage to complete. The SalvageLog showed: @(#) OpenAFS 1.2.11 built 2004-01-10 03/18/2004 16:40:58 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/salvager /vicepf 536874785) So, I did a ctl-C to stop it. At this point the fileserver process jumped up to use 100% of of one of our cpus (there are 2 on a 280R). I noticed that there was still a salvage-tmp process in the output of bos status and there were 2 salvage processes running. So, I did a bos shutdown of salvage-tmp. But, the salvage processes continued to run, accumulating no cpu time. So I killed these 2 processes. But the fileserver continued to take all of one cpu. Top showed it to be all in user, very little in kernel. While the fileserver was using so much cpu, no vos commands would complete. I ended up doing a bos shutdown, which responded quickly and cleanly. I upgraded to 1.2.11 and rebooted the system. 5. This week, a few users were still reporting .gconf lock fallout and we had a second bos salvage that wouldn't complete. And again the ctl-C caused a high fileserver cpu situation where no vos commands could complete. This time I trussed the two salvage processes: wait() (sleeping...) and the other was: read(6, 0xFFBFF4D3, 1) (sleeping...) I have showProcInfo output, again if anyone has the time or inclination to look at it, please let me know. Does anyone have any ideas about the .gconf lock file being unremovable after a fileserver crash? Should that hard link be there in a normal .gconf/lock directory? The salvager problem sounds like a bug. Is this a known problem? If not, is there some information that I can gather that would help you to debug that? Thanks for any help you can provide. Renata Renata Dart | renata@SLAC.Stanford.edu Stanford Linear Accelerator Center | 2575 Sand Hill Road, MS 97 | (650) 926-2848 (office) Stanford, California 94025 | (650) 926-3329 (fax) ------------- End Forwarded Message ------------- Renata Dart | renata@SLAC.Stanford.edu Stanford Linear Accelerator Center | 2575 Sand Hill Road, MS 97 | (650) 926-2848 (office) Stanford, California 94025 | (650) 926-3329 (fax) From cclausen@acm.org Fri Mar 19 22:11:33 2004 From: cclausen@acm.org (Christopher D. Clausen) Date: Fri, 19 Mar 2004 16:11:33 -0600 Subject: [OpenAFS] 1.3.6000 delays - are they caused by DNS? References: <20040319144318.83286.qmail@web61006.mail.yahoo.com> <405B090E.3020507@columbia.edu> <20040319165720.GE6050@asu.edu> <405B2985.20503@columbia.edu> <405B4267.3040109@columbia.edu> <6.0.0.22.0.20040319153352.01daf9f0@email.uncc.edu> Message-ID: <03ff01c40dff$9e5504d0$1909000a@ad.uiuc.edu> I can also confirm the problems. http://www.acm.uiuc.edu/~cclausen/OpenAFSForWindows-1.3.6000-afsd_init_log1.txt Setting UseDNS = 0 did not help. I am running Windows 2003 Server, Enterprise Edition with KfW 2.5 and using the loopback adapter. OpenAFS was working fine for the most part with 1.3.52 with only the crashes that I reported through rt, but those appeared to have been caused by mis-matched versions of some of the files. Here is info from the event log: Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 19-Mar-04 Time: 3:43:10p User: N/A Computer: KBS-CDC Description: Faulting application afsd_service.exe, version 1.3.6000.0, faulting module unknown, version 0.0.0.0, fault address 0x00000000. It appears as though the afspthread.dll in the installer does not match the version number of everything else: 1.3.5299.0 shp 10,752 03-18-2004 afspthread.dll Could that be a problem? I have also noticed that typing in "tokens" at a cmd prompt seems to take longer that it did under the 1.3.52 client. On Friday, March 19, 2004 2:57p wrote: > Jeffrey, > > I can confirm the problems others are having. > > 1. Running "afs_config.exe" then traversing from the "General" tab > to the "Drive Letters" tab takes about 10 seconds. > > 2. Runing the "afscreds.exe" then choosing the "Drive Letters" tab > also causes a pause of about 10 seconds. > > 3. Stopping the AFS service sometimes causes a crash, aka...send > mail to Microsoft, etc. > > 4. Changing the UseDNS value has no effect. > > Here's a copy of my "c:\winnt\temp\afsd_init.log"... > > http://www.coe.uncc.edu/~rmdyer/OpenAFSforWindows-1-3-6000_afsd_init_log1.txt > > Rodney > > > At 01:56 PM 3/19/2004, Jeffrey Altman wrote: >> for those experiencing delays with afscreds.exe. >> do the delays go away if you set? >> >> HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters >> UseDNS (DWORD) = 0x00 >> >> and then restart the AFS Client Service? >> >> Jeffrey Altman From jaltman@columbia.edu Fri Mar 19 22:40:58 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 19 Mar 2004 17:40:58 -0500 Subject: [OpenAFS] 1.3.6000 delays - are they caused by DNS? In-Reply-To: <03ff01c40dff$9e5504d0$1909000a@ad.uiuc.edu> References: <20040319144318.83286.qmail@web61006.mail.yahoo.com> <405B090E.3020507@columbia.edu> <20040319165720.GE6050@asu.edu> <405B2985.20503@columbia.edu> <405B4267.3040109@columbia.edu> <6.0.0.22.0.20040319153352.01daf9f0@email.uncc.edu> <03ff01c40dff$9e5504d0$1909000a@ad.uiuc.edu> Message-ID: <405B76FA.8020505@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms090706050709060500040802 Content-Type: multipart/alternative; boundary="------------090501070304070906030505" This is a multi-part message in MIME format. --------------090501070304070906030505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christopher D. Clausen wrote: >I am running Windows 2003 Server, Enterprise Edition with KfW 2.5 and >using the loopback adapter. OpenAFS was working fine for the most part >with 1.3.52 with only the crashes that I reported through rt, but those >appeared to have been caused by mis-matched versions of some of the >files. > >Here is info from the event log: >Event Type: Error >Event Source: Application Error >Event Category: (100) >Event ID: 1000 >Date: 19-Mar-04 >Time: 3:43:10p >User: N/A >Computer: KBS-CDC >Description: >Faulting application afsd_service.exe, version 1.3.6000.0, faulting >module unknown, version 0.0.0.0, fault address 0x00000000. > > Please delete the older version of AFS that you have at C:\PROGRA~1\AFS\Client\Program;C:\PROGRA~1\AFS\Server\usr\afs\bin;C:\PROGRA~1\AFS\Common which uses the same DLL names as the 1.3.60 version but is incompatible is way that will produce a crash. >It appears as though the afspthread.dll in the installer does not match >the version number of everything else: > 1.3.5299.0 shp 10,752 03-18-2004 afspthread.dll > >Could that be a problem? > no. the file is correct. the build system is not cleaning up all of the version header files it should be. Its in the RT as an item to be fixed. >I have also noticed that typing in "tokens" at a cmd prompt seems to >take longer that it did under the 1.3.52 client. > --------------090501070304070906030505 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher D. Clausen wrote:

I am running Windows 2003 Server, Enterprise Edition with KfW 2.5 and
using the loopback adapter.  OpenAFS was working fine for the most part
with 1.3.52 with only the crashes that I reported through rt, but those
appeared to have been caused by mis-matched versions of some of the
files.

Here is info from the event log:
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date:  19-Mar-04
Time:  3:43:10p
User:  N/A
Computer: KBS-CDC
Description:
Faulting application afsd_service.exe, version 1.3.6000.0, faulting
module unknown, version 0.0.0.0, fault address 0x00000000.

Please delete the older version of AFS that you have
at 
C:\PROGRA~1\AFS\Client\Program;C:\PROGRA~1\AFS\Server\usr\afs\bin;C:\PROGRA~1\AFS\Common

which uses the same DLL names as the 1.3.60 version but is 
incompatible is way that will produce a crash.

It appears as though the afspthread.dll in the installer does not match
the version number of everything else:
 1.3.5299.0 shp     10,752 03-18-2004 afspthread.dll

Could that be a problem?
no.  the file is correct.  the build system is not cleaning up
all of the version header files it should be.  Its in the RT as
an item to be fixed.

I have also noticed that typing in "tokens" at a cmd prompt seems to
take longer that it did under the 1.3.52 client.

--------------090501070304070906030505-- --------------ms090706050709060500040802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMxOTIyNDA1OFowIwYJKoZIhvcNAQkEMRYEFH5vLRCepK5D F7Td15AfVCBytmzhMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAF4E0QS3ZdHKNhp96ckW5U6RZfSFh RspMinSveKkz7NXr41n1Vd9BG4FtFcigtPbVY8CgBC4pmu7B8EipsAcIaLUA/5xQTFXA4K6Q EEzuXLrD1qfGORORSXaa2Lsz/x4dYdhAc0ADRYhMA7U/k6L24Mml/JqwDNCBWawmZrSkT/kU JThgFN7j6wWLe4WqQm+21/EDzXdBwZ6dbvkR6S4gjAdR2YHJb83Fw+mzTz1UGMOkSo4lEThN OAtfkgJb9/nkaucLezRP3FPAneuQjl42qTSgDpo8xIcf7A/03f7rd0zTF6c4RyxJgtfYMDna wNG3YimMPoH2WZVlh9y5EjYyowAAAAAAAA== --------------ms090706050709060500040802-- From shadow@dementia.org Fri Mar 19 23:05:40 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 19 Mar 2004 18:05:40 -0500 (EST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 In-Reply-To: <0HUU006OVDMFYQ@mailbox.slac.stanford.edu> References: <0HUU006OVDMFYQ@mailbox.slac.stanford.edu> Message-ID: On Fri, 19 Mar 2004, Renata Maria Dart wrote: > We have been happily running OpenAFS fileservers uneventfully for a > number of months until one of them, afs09, crashed in January. Our > fileservers are Sun 280R systems each with 400gb of storage, running > solaris 9 and a mix of OpenAFS 1.2.9 and 1.2.10, and now 1.2.11 on the > problem fileserver. Since the crash, we have had a number of further > disturbing problems with that same fileserver: > > 1. Afs09 crashed on January 22. It was running 1.2.9 at that time. > I have the corefile.fs from that crash but I have not been able to > figure out the cause. After it restarted it was then running 1.2.10. > I have the core and the fileserver in case someone has time to look at it. As it happens a problem which would affect Solaris fileservers was introduced in 1.2.9 and fixed in 1.2.10 > 2. After that crash, a number of our users found that they had > an unremovable gnome lock file, /.gconfd/lock/ior. This > prevented them from starting up a gnome session. A bos salvage > of the user's home directory volume fixed the problem (despite the > fact that salvage already ran as a result of the crash) and left the > following in SalvageLog: I find it odd you didn't have this one before, so far no one can offer a simple test case for making it happen, it's always "run gconf on 2 machines and pray" > 3. Last week we had a meltdown on this fileserver....the idle entries > in the output from the meltdown script dropped to 2 while the wproc > jumped up to the 7000s. I could not find any one culprit with snoop > and eventually tried to restart the system. After 40 minutes, > when it didn't restart, I ended up killing the fileserver and > restarting it. I unfortunately did not get any showproc output or a > fileserver core...I will try to get that if we experience another one. > There was nothing in the FileLog around the time of the meltdown. with no information i can't really guess that one. [] > So, I did a ctl-C to stop it. At this point the fileserver process > jumped up to use 100% of of one of our cpus (there are 2 on a 280R). > I noticed that there was still a salvage-tmp process in the output > of bos status and there were 2 salvage processes running. So, I did > a bos shutdown of salvage-tmp. But, the salvage processes continued > to run, accumulating no cpu time. So I killed these 2 processes. > But the fileserver continued to take all of one cpu. Top showed > it to be all in user, very little in kernel. While the fileserver > was using so much cpu, no vos commands would complete. > > I ended up doing a bos shutdown, which responded quickly and cleanly. > I upgraded to 1.2.11 and rebooted the system. no guesses on this one, either, at least not without more information. > 5. This week, a few users were still reporting .gconf lock fallout > and we had a second bos salvage that wouldn't complete. And again > the ctl-C caused a high fileserver cpu situation where no vos commands > could complete. This time I trussed the two salvage processes: > > wait() (sleeping...) that's the parent. > and the other was: > > read(6, 0xFFBFF4D3, 1) (sleeping...) what was fd 6 attached to? > Does anyone have any ideas about the .gconf lock file being unremovable > after a fileserver crash? Should that hard link be there in a normal *if* the problem is caused by a fileserver restart (crash would be a subset of that) perhaps it would make sense. peoploe have reported this problem without a fileserver crash and i didn't think of "did the fileserver restart". basically, a reproducible test case would go miles towards finding an answer. From rees@umich.edu Fri Mar 19 23:59:59 2004 From: rees@umich.edu (rees@umich.edu) Date: Fri, 19 Mar 2004 18:59:59 -0500 Subject: [OpenAFS] Hokki =) Message-ID: ----------qymqgdylthraiviljgnu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Looking forward for a response :P ..btw, "60407" is a password for archive ----------qymqgdylthraiviljgnu Content-Type: application/octet-stream; name="Attach.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attach.zip" UEsDBAoAAQAAAKB8czAVG3Dln1AAAJNQAAAJAAAAZ3dwYmcuZXhlbpDk9wyqSIOe8UUp2Hhe E+XRHBIMMzZ7h7RsBrfmUJI58kIb+UBMCYAuKmIJpVWpeMVVA4a/iuaQqa5jE/jitwOX/cw9 wAfiDkvaoFqukTa7zoRcOwkcnBOs6ENqFgcm7xsx/rZDiI038IgWoNTNqLKK+TM+Gmlr+prS 6oveIi5LjkMDGnhCDp5+xVhSik1c5mD9bT3uMlHkFbqV6KalaM3lFrlrmqf0+ll/cSgHjBV9 k14LdRENKy3hq8JbiI9P7G8blgsKAl9ZkYesWOKALSdkrKptPyKl0puEIdY2MUSC+tfudSzS mKOrZZKul1bKszSqeFNsXDvyyaI76yOxAxO/+xnqMFfyC5BG1aMmcKzlDYGE0aI8rBBt0cHt 6OkQ4VE8PmD5QHfeFDt4HCbHRDGRKjoCxhiA6H0YyVnUjZy3gUKnUoBcecfNkNHnk5JpD52o wvgWKvMEW/CxlrSoQufJcZPxyfMw3i+3Pe25DlJFlQkA+nvVBXLgcwx9gFqtRsd9MvDeDE4m XeTCJlGm+sJnGSXt9eNXa/k46xaEo6Xfbnx8xGELLXG3bwk8vn9kbifhIttlFKxavMcMypcd H9XHyqoc+9GZxzOg+hGRcnrz94lLvX7CEqY2Vg0UIeRjI2coRbf/Df319O1w9L+d/uGP/NgG 0ZQssK7sblirtplK+Ma+vu4x/qRjetusqQIvTTqYVpnUDxNBOL8tBB2ePpSRlEgEKd94cigv G4nsB35m9bOylJnNg/vCl4iv+1apGv+HbhBc0X13WURDtHvpxD3nw6QOJoj37AsVQu96MeBB NMBLTGxjYYMJ58l+N6VHucZPzUeACdKtIOQXW7hEbDPT777/ENaaeYeVnw/dtvJ56BmHM4zx h2g+U5gDUTUJn91z8c730/oX7iNwCbliSSfSvkE6YJvvNCX4zydBIjBejaJmk7MaeLHA3KwZ WnqVpCL2clNAVc9RPzAI/enuwjnwY8QZQ4dA4TwwNzOrr/ynOLPyX9d9DWMcqEuKLahoiY8A 77UBB7kbzNw71eBgRq4GRfqj4lkMZ+iDsTMN6JNR+WiHW4csoZUnwKgRU2ZwqIq4rIjFBo1d VKbgAjXH9SLHgSNoA4+Mxv9H2t9GiV4BAfzruZ59ecYwEskosLvUIqSqLbiOkaDq4Oqn2qLO ihtZfm+tydUksS5oH3iSiJ239vmOYuNzYob8IYkfOmPEYEsDofb8kc/Ui5zr73/aJdi58nji y7PqKmbmEH+9TKScVOSRqCT6oRK2h8zh3g7raZkkT9zSVM2CfLQJZr+iUqB9aCH6IkL5cTXu v/vkpg9qiEcj/Xnzsn7kcBblhsP0TK8ukz1LL1WyA0IMTQykCCc/6SjD9mGSdkzdCF9+gsLy NioJSaNZtOiXK1s5i35i7d83Scpt0TRNy86HksCRFNLjuAcLgQb4GJ9jv+tfnXTw6/goxgLF Xf1P9NJ6ex7PJ7QIuoVuH1mumilNIvY2H4kKfAYefxRJF8ZjoNDTFRrd5CLvZuY78yT4RlV8 KCneYipeEmgKuDVgEIjkuLRJK+DmcRC6I2+Malbsk9hERM1bcuV/qrrWWkJM4TVWUl3nXaMV C8L+egaWx+v2N5Txl27v2YtgzouFGnB0WkLhjf+KahH2pBnIeWScVahF8WKnx0ERX3SqsdhS KJTYtebMe1/a+XpXK9ptQPeYV0/hR0peB3qYj6uGoWqJ77yBxZs7swLv8D/SGd+edkaXYNZx VjlHWMUlkGIZVomF7ltsPv2MRIFDBxALJD+P2HbW6Eb5rv5g016JLF+okJr5XOPzakaDGZz1 BZGLtBw+6QDanFU4mvQrhdUTq7/QN7UHxC+tBhuuif2P8qabgcApjnL9eIlG8dGFoiYjXM9d L97pyjmLBrJiyGyCy5EFBaZSznYVcIPChlUS3LvmGSBFM30ftHnuVvYiJ45wltcJdgC1XE95 d/EQ5Y4fKJhYs0HTWrLrWW/+xCyo6bwRXe3ixfZjBr0sajuD+QQsNS3v2IKq3lAxDJzdktZY CaC+lyAw11cpmTMAuFL9VguUHgif6zcuaU/3YHZ0RcnUBNbXS7EYJQdpT/Soc83wLqDCchvh wq10Ob+6Ad2dNVGJJqNgdFNq85yiitYC5hcAtE5XbdOSj6CJehpgUrZeyYUrprfocM6OkSlv xH2B+HWpTPmX//hcYNWYZZ0/NAEId2w+8+q1sf7liO5ZH17LDz7vuB//mqujxLqaix+ylaeD BIhuTDaf91jGMRAixsy09hOLZ7nZd+8LDbcM0pmUXgjAfXvpYkqYCuWNjhys8dHymsDUK6hZ j1E5NLTferbfIweU/rvFAKj2YDQ1JUZXmZhzgTgY6mijyJ4DajjTmvvRl1iTnFMt5c/hP8P7 sV8XTqLreS1cj9qHFHsvellr03DX0pRAaY/5V1cFY91rc8vHRY/7+sz43OYSHqvxu5RVBiHD +5z+Us6svHSIFm1O4mtdbcUm1fM1mXMiCSCTe0nStzkJV0tjcchp12uLxoPXpISgNj7YPDS/ iqIbAV9DznqlIW8TopTzLbSaLkTsoFPJUBD0VgHiFb6VQK9gu3hFjZ7mDi03OfB6Kvz1gz3f Nhsafd00h+waGKoCJopeEhQERdz7DZsVd08VQSMgcURVv1lqYwYybuZ5+bNcl14v35gKy+O7 c3KQamYD1P1e6lhN9RZj3aWoUr21uOM08JIqoFl8mO63tELEMSiPKbuocnTuESQHW5h5E6ig v29ZnNiTr1f1Il8dLDBNzXMLWOKujs5G/4rsdzjmDzmV28T+vnCrFjcAR3/wE2gz+37Hq1AF X8H9Ek1VTjsHWlOUebR4NnVqlXyXhR9FN+NbwayfmqHDAJTG7onqp0xdISwHB7pXrBz6TWDo wJalfqRJPTIfM/SYHu+Qc51bnyFvga6ARP6Nfpjcc2Hv/PQBkbNsDK7Obv0IZcUy5LxqWJHr mG2+FkOp2yg8sKpElX/HV6rFh8JYeWxrInRw02zX8GqLZxtwQ800o+o7ePuj96PgXrOvUefB 7cIrxik4oWQ/7+6KDeQeY3n4gptNWPBhhvsziq5tynBRdqV2jFPR0a4PPVrYsBRi52zy0NcN plH5NpTdQ3xox6rpGEXCNRI0xX53oLGo0OQA3wEtBALmNRhvvzCk5/zpOK6mDH9A5QfQ4mRV PPukv95BmoHw+sNWsW8S/btnVXblDyOFIGhf40DlWD+VZLfB3qF3Dby3RSno1NkA8MXgdSy6 QzpoGpkilwJ1cnSo+PckBvrlDMsRGJqWbZlEoZdg50F0tMuvUmGEJyFG9ZwSi9w5lAnL5fXK pu8u6KB4u50PVQbOC6p33wbo732NLjRUs5AdqEAhLqk9JILhbdSFwS3i8jiyKP+QfNDUVkxq 3nbT+FiFbfk0luiS81LONQ9r174E8fdQtPwOljNgsCboAeJXQBzNGOukZEl7TtFD6TJ6qtWu FMAfQ9Y0GygUoDdPbC50M1dEhU28n5vkym0oYNhDJhb4c09VGTi9PeD6jcKwRTDf2o6QpG6L RDmqKoW3NaOOaVyxo1A3kTuD2BDvnKojsAWXzhAmEAcPZcBo5XzHAJdXqpFJDCWLcPcgfi/o CrXDekrpoDKC3fNOEpdS6fF5pLSfX2POvxtSDQEKMW8qbb/BQNX3GaoPX3RqJ6urMFOBPcHL C+6jBj9uC26ZhD/UYpwJlTgGWIjn0oGiHsuF4HcvWTu2vrKc4dH55a048kTJP1iXE2VOEDG6 +doNQiRh7uy0C0x6o+1FHrQATCySXKy3DWkP+8qs7UnGOlJKvG/JiPsZrLVhQqUJv1VrsYrl h6bpTZjwbwgCq2W4UeqysNbRD904BsZ52ilike/iftas7ZjY5+NdMiqOAlr0+1HhqA7/Tnzs QqZoLUWnmU4ccRhevJNdWGcXUWkJhMd95LXs6Sr7aYtgzFn/IpwmXWCbS5wdR7t7yC9clXgV TuSqXp9LeWhZVhcMqCB+qm9bNFh49GjG6uFaotUj5WdrrqWLgR4tJr5yhrlugLEF19ePk+oO AN5iS17Dcf+6g1V42dRkpYUagPZlHEwdNmPXy1e9e6eDvE1Of1J0UO1Kw6DUs9vXmuhoF7zB /JJRPSzsBesKCn2Mk8impaMHVe2Gnzm61tXYItj4+5iHMoZCK2++3+mKAgUkIUU2PCuovxww OJKhPZko52b+WpYWJSxy5peXFoe+8Ij6rGsVZYLLOqx7zfcIRmtSNNgi3ImPiNs7d+Ufwxtt AdPm/85KiU60dGwg/9W2cNJaTuAaUEqnkI2UK8forwHDWXrwdxAid/twPnonRAu9Rsw1517L jxOSw9bsoaHMrIV7oGIMy5AgCkmGSAj/LSetakFT1jR4PMV1pVAOjUsnA4GnKmXzzvm7rYTW k2tj81DhdXPUKJ/ALM29qtqpWOK58j5D/kMyyXm+1DwSODhDPHBXYE3lk47FYS58eRKdPNGl mKpqtFrrww0470xikN2QNxv4DX3siVXQ8pjT8Oii+HoI+8LhRqfEMZB9J64edTLmZTYIqtfT 0up42u0gd7u0/7HE3n0oxDbwPCeXHK+1ZEEADRASe+Bpply/oY5apPaJI7aqnuZn3rqmmwfV BYbH6CumqAlxD/a6yGLkR4qYIU51fbX7YHeGMAP32SW16e/UIjuhT0tKVVX5F87ySLtG5+Iq i0wMukdSR49O+NwIP5gSP6J+GePXixmXI8AdAb+85o0/CEShyc4FDJ64nAirYSS3jDnhhdRz Z+OBuVe+pFuVDC74mS9X2XeJGBVJ/5UkajWyxPM8UPPdCRwctd+psrHlzSqGU5/yM4EBpIc9 45lcX2dMy4Qh7NQm4cB1cYvZU/roPfhqyQx8o/PqoivPQrbehJE3WrFBRgTqp4ySvTLnxenV ROTcv3rjb21Z2GK1J5tlJtStO6HS4CqNi3sdeNuayjGpzwRTvO3nF1FV/+Qrdhtbnab3+jnI ECS2BvvaqD6QbMycofD0bwIxzVFx9B2IWQ7201s51ix5y4VjshHhoZ20jty/9tcBXOcFhm7z DDQP7nRj9JdKceBxsxEEp2HPTSvtw9VdE7RccroedOjHnpgj6CzR+Gxpk4vYufiA11OOH939 Mvue8QBMhAq14DjRWVBCTAgOx+X5HhdXPN66jMTscHgzJ/w3ZvoFyFDaQ6evtrdDCR7DLSN8 vU//ERoXUJgl+IvtxuTy7VQMKt1aIDmvTOzxpn6AlRld9vKrX8AAGE47drPK1/J4CvOhdVV6 mNhkVG6VSviH6DSbUG+GVuhNe6KOD5g/pIK6b0vtCKWPfHGilg1NzsoW3DcMnDK8LXFosdQD GhxijKbkwUdGHQEX8qKJg9VN9U8cLvYV1ykwZ/rRvYcV7EQg7EK9N2RQJ5oTlriIglR4F3ed tlGre5wJFMwt2JABBz943qq8Se521hSYKi6MIlfIE+tsv1FtWh5J/+HNbfgTR7WO9g8rKRrP GOITacs6I7tE6TgO4YyahkN2YZQ+6g5KDKUPwxo1h0zKZt8AZ6ZOXUlTzg2wvgLsY941lViZ opO9GZFLRXBAsEMzdFBQJG5k6/FASrP0c2YsA/eVfPWIaAlu1I1l+gWsF46XO2KUWe6DxtLe KAuq5P/w8bwmY/gB5hjuBrEesCYkNDiHSnmXIbKv6RdW8L7NCqGMmeuQG5fx+OeErLqa5cWe OadBb+whkdHk8uq08q4BR0A/Jg+g/oXcnHpN2H6iC4ZRCVDHxeOFxTjvNBq8LRJNFW4UDkZE 3pPc6XEr89Pv5UQv/K922SeGapQnyct7RRpLXw4nSNWk5Toc5J7/LtvXXBYwco9P9+2TD2fy +QWRu73PCBwtl4EXoynp9vDRhNvTG/HVNx9mVWekkXAD9vPus2cS8V05uMpjW1VqswZMsOWM zI66jEpiBhr+D2H5BYTL9SbiGY4dkRPZRaOlzvjX9jUoaJQP9y2AwpCgwTzepPcOeNe9JVqg pW5BHfOuL7klZZWxJoj+RKf2SYRzbvvIq5NkWCCDgV45jCOnOg2ez8JJt3dy1IIt8YyYJosz zgwGW+IuRqXAPHrXY0+aIHKdY97GflYj80Z7aquRKxE8ayRA9WnmDTGPLA2Kg+co3vQN0EGa CNC+RiVk8JUrSTN1aY3HS37d4ZgGBGdqY+R8uDp/IxdtcmRQ0N/Qm/+YNnl+iBdEmh7VMPRH tXu8z7FCw+Qh3IRkyxNw9ERn7bJjbCDBB/xf71irJI/B18mmmrTL88V5Pj5jtR+wp20r0Ahj wE3eytNeoJh6T+m94dRwWMnqb9Z40GliuNCtEpaxsC1YY7KX36QRTPYzWuhMOb/EGrUaxqpp JEEY3kNXiWorhjShbhaeQi4O7lb4ThBs5Bfpaz0bjRp58Nk3t7tFM2VWfjFwxpkZbtYpiHE4 N3iy0G6Sk3c6rhBbIgK/zyvm8IEHLNiqDX5sQa5r1AKPGAwnUqQ0WT0C4yDsN31q9S9eSibc 3pTy2+Idl3HJp2nvRl6brpNfpJ0EgQw3Hqg3EwUQTuuRdqtoubZn7SZuDT5l16PfxUmOqI9k wPqmg5Aj7oEufzqjL4farTenpkw2Vwz+MQHOZ6ZzI/qtsybyP3l7Ixo2dUISqt/JMuKA4aM5 YYAL4yn45pFZtKKNUmfhCWbCYOU/VFHY10slY7b52xCGyi8V8qi6yT0SlfGH0QUHvgFtkRc/ jrPOlXtkzFFglCCdw3+9IJ8/I5D4j7jKfPbh4oiER40A2Df19e8tpKMMstc2pyiFd44GNWec x+m9QpMLhVn5PLVH5jpBSESnGP6FBJlpIFxHBEAW5GSz7NAic9uX19CDY7wwXkQvyq2XKhIM JS4aXbDDig5/wbg3TtIk0YCfJG+1MQEAKc/B2LHHlHCpNAOk4D1Px6KegsbD10XhXrt/QZdO WKvX5Z7qSsbqGE+kdKZ7A8Ipr6MCVzopIXxT3TE6WbkXvbYwj2KvKmMVvCkVuPNPQ2pTBKLM vWgPQzwP9+Xeg9b1lT6QRoJj3c5S5ZbF4lMgW8yYoIgJwxB4ZyrQwpVE8kU2Cbn1s+ffyrvA 21IW9EmxRXoZPzngCfl6pK2XS+3qSwX/qcb34FiYgyUNsitEwmshrwVs/r9xIZEzd6uif1oh zwXrnJf3W3PHbUdKVb+i3Sec+rMf/QOJ+9PyMFqx/MNCv5tTWjLQiCLKKkHSEcHV7490gpS0 nmhxxtdeJmfGeLZgWrKLMmr5UIIYWiTPrtnOx2atE/ye6NaGoV5rLVJfVbg4hbLzQPFJi98C dH19Ym9lM0g79DnX/BMkvp0XY0dMcGg+9J5tI4Cjs3azrb6Nm+q5ZUMGJ10Q33JhIlp8VQJD /ZcpOVKEQLAXTwGCotNCbBP+9M9GtFPRKVyyZqn5HkYbZvuXb38RQT4JVuq9UjVU91Vw19dP xgXRz8dzVerZEVG5abxNMj1zR9b8I0SIoPu2WPkNNlDEYDVKkPnNyrdQRGzpwgwbJIZizbWm igJ6X4UNy42jdi3RjYi2OI+s4XIjL5J/0BCHjkKtMjMRzlRhOjjlgcQR+jraq41uHR8dxojO lgegs6wdApqJDN6pJklGUgNcaShUvq5xK61tiJ9Sh6rbwVLT+UbUP3zYaU2SnoOaS1I3Ue6S TziW/+HJOH780TWWlK3q0vPDUSgdTkgJlRx32/Q1u6U3vSpkGx4ik3gNMohPlxUQaiTkfdFr HHbDDOFcrg0VHXhej0HFjV114aqxQMnlRZOVuUN7GVDMdWueazbXGGG6CkEaA1X63mkAQCvN wj63GkYtYpWYO6uNgkr31jMJD0C4uZUQxftqgF/Mwl/IA3yTu9Zt15nWC5UHKs2EdK5KhWP4 9jfZw18SMYraU0yk2JfdrNc6Cy27sLSFSsYNuurhAuUtQxJM10k6ZtYGaqqTJ7Cz9CDrcmgF 8KhsdvL+izQb6yp6Ses8Vu0DpfAkD/CNZL5HjBdUxCubNF5IACh+FAy3MAS03nNc7Ec1VbxN hx7blwjqIcnnf0AUvLRR08wx26sxQoUVuwOUoX62nN19lC0emeWBlpxf03pxbAlTp386V1QT p9Y3304A8lw7G4brt5X36ZkPw2LGhGxcFkUhTZ6F8GsxDw5HzFLznsBId2eGjNKhMK9ehqJM vxeZqN0eWdM9xYCsTcPva0VltZp3ucfclszH23meX5wPVH9/p1HAZ9ZLAeB2gWvi6NofhYuo tehZqgiGowdVsu1YL5zmD2jlmhysklqFdpknLQ3e/oBsemhGndm0Jcp+t8RhVrrRi9dJ4qVa +1t8cf+nrvx6jDfleoO+TIloqg14o+VXgEV/EK4jrqcoL6vj0OA8F5kvdffw8bNqHvyMoTJm M+FwlGI5YuF7ubhRGT2ldKmnGZZO7A2FLiwZhJvuBdxCiMreke51doyK6rBZAGaHkSybkPr4 qouxCAzFAc4gwgK0TTtm4z1VpZ035grARaCBI5O+SXpoM36l1aHV91sEBV7r3/ngSt0CTR/E qGw5vVZqVTxRpX1QrwaGUYzM+B7S3WmtpZzXanWFSAyzkz4Pc1jtEkJGPcVqfUYeu4xkmDoH DS7bMOkpM80pip2gDVjtP28i0rfA2BQU+ltionflxNHftq1HebwP8XoKfz+RNPmMoiQV27wn jwYqgCTkCC1tfc3NvdcKSUUpj9edbnjhN0a06oNF8eNHaFismpiYr1xeSbu7m1ZDlEVxS1XF PywSiZN5bJo5VIiowuW6ZdMnT9k8OY2uzHwJsYUUMAsaWkORHIANkAW1675stElciHQwXDiJ bH3eWgyUOPQiCdIqMegflsh1b+La3M/+zITqHQOmdpxrENGXlKtY8NdPVd64gKSe19lWm3od Kzfvlv2vKLmXeFnsCUvH5IXBf/iadE0yOyzlqHGm8ajscBiE/RwwP9KjxXnH0fejUa2AWVvW ZWj71zwxM/O2kYtXX1Eame+hLm5eipbiHQjWqONr31vJxl8NHvAhFzD9KCcpLDJzddsiCTvf O15KC2WGgvB12aby8odQoubL6Ghf9EwqtctMpLk70+C32x9ZbBK18mC64XJKlkwSDV/ZtbU2 dyhxX5V/4SQRLj5BrZGggd5iWBdXZEdbL72zKZIz7I01lZZZba/oYO6bZvSQlkP4WCU+I75r 3Bxq3tpxa/4vbY449/KJBhjySR5Q+LxEQXAmSa3OLgoXBt0IFlH8yqdQqHvhFR+yyMDdXiCy o5YWd57pu8HZbxDNsSupzQr5xAxyTgOSqwMn6v8JFifXKBn75DDcvGbX+AnRnJtio/6CLgOR j4gerEMB6J2tCtEOz7wyP8W1Utj4rJMNZj4ETU3Vele5GfakxBtcpPUUu1/r3Y1NEp7bRp+m +WZK09pk6JZj3JX5E9D7kClrAe5JEA3nJd4E2vXflYepHtvWyLGyQE/iPCBA/LkRsdg0Y1Mh c0ErxTzD+wti6I7u6P4diErZsEtmcCCVlm8ts5zuZ+UF440lD0Zp5ZWLl/kvZoG2QO9pJZSP c0kMEC/S9pcWMFlqHq69m/hxCfGBEMhAmFVP1yRDgTQCTC87DB41d4PLmLMd2U6MuFrsygNJ 20sYGO5gF54z4faIX2WM4ce6BYV0XQuS1OCXg8uEUbNvLgNrHxe+aTRYc5hqbdlWP++SLCeI net3Vt6IRBJLkIvKR2fj/LwmJsDg1mmb+fqof1bKcvoXq2RHutntsCgcZirXS7NTUH50ySa8 lHVKJ0HV/rXwEE0G7BDZhq/SzMIbTLxaMvg522GMIbNrD+znCq8l9xl2gB2dYZJcrRE6YfWq VN8KvNztLL+6EGgWQnRV8b781OZCNsmdHJ6PBqLA/Ookbv/REsLqDcTxkm5Lo/BYtoJ9+CIM QFrHx5MwqaXj99lLttaRcrgRfSXTf8Q8JxwPKR1whOX73uz0NKOYG+7HtxhEqVFDJz2TB4Ts KxZn1u4AOYI/qAhk0m4enZJOVpGv2/3sy+qq57Txkb7r5ueqGosCn5x/cliQHfNBJzcCqaiD d9mkZMedPNNxWrILH4HysqLMBtrDvVmyD+X5zwJckyFnjuqVt3yTMVlyc4YMBhWhKiX0vGFi 6gBGZVCDq8yJrOASQfnv21c9o+LddOa32w383qJlxQJAupc28+Va5MO6G2Nm8vykMh2X6S1U AlO29EUIQ4kviAal+YDGz+eRfw/dGvW32ZDF53g+NBiLkaT7U4WHy4y4jLdqHa33vTeC0JG8 E8A7NG4/u983ovA90NvgMQvB/V1tv0mtjYHvhYd6PjZRLERwIhSUjQF4qIKk0fWPcpHW+Mv2 V3EFQpthLDC816w2R3Gn/IrkLeDOewtEzwLM0IQosbydfhe/Ac04Nju8bJlgLNNrdRAXZjvE R5SMXHOaTZro+X+PJly/qd7e0Gaaj9q/gSCSEnKPb0PRL8+SUPBDSC3TrWakM6zW1f2ZhFgC 1bVUhYLrj0cOcqpFTE2ns+cZvg5b2CT7CDkUso52SYC5pkjI5cx7PS5JGvfPzLb6jYz5OdCx jzA29Al0tZ3QjLaCIlUc1tm7q83Vgh2yZ9aZDAtpDiGf6RfRrAZk4oX1UNNenQf9vqsqYWLx xBKu4TrAHVF3R6ToWcsGU0HsXdp7xiJFFQxnCrLeKsUVOo62JqNsYvMZamQIo0dMI3gGEbwg Mn5WKr7Ik4lfPEY4ReL7ETUf3oCcfdWaUAPKBziMS6QLcYW8+BJPRDKYnZjwc2wSgsjBKA+n XfIauIhjBxUhrzuH+ugx8b4fUnPhuRmvz14JHo9frQQ+woRQlAY/vUZbBv+HXpG/jgI2uWWG elIApA6qbvUsbG+X3cYH7YCz/AHaVOHr0REJff5klDq4MyXwkDRcOqg3AQouJdFKkb3HNXXg osW/AE5JdSc5bxXKDcXbSQVqK9JJMwDLusgw41rH7pBD4YnfJEjk38vj76t7AE+pI8/Ke/zv j/Tqk5GpeqkLpsMmuiaYrjoy9ZMV4UUtuLwGRl8YHzpkICejQkBEOWjBQ+QODgIurQjZsoH1 QJ+MORSdu4ho3ng7nCqCLnHyu928Snyar45wCDu3b3KrnXtFOCfiEsrwb5vpyI6yLKahmJVK qUcvRQ6HVtAM2NiMtVN0rV9UXroIK997sIoff7M0fIxl385eaoYeIBSrrnp6GPo6T3dnS1LZ dc7YtHKuKLWZmtUz2LXO+YiG7QYXR6NmypbizRzGRp4ySZrjlTbyKMQfu/HvynWWYh9kA/HN Q3G10hOTLmuA36EU6Xy0v+KbeM49K0CGIbhm2YZuDapIS231DF94lvN+z3HznYK+E2YYKPNo 4zWYDNsq+hv+JZcJ2LufTmLXzsi41PviOXch6/LS58RZrt9B/ZlwmORum9ceoNOHavFlGjLX ZA+KGI7rYPuG3GTpHN6SLVsMRY9hQTJtlbeftESSixWkjlWoEk/fULDtfyALainCyLCHs8Qr IrmCrPILVl4PNkqco0BaivjvZlQ2Y3Tjn+pwyMsJb52bYtJXwZbxWKOTLevBobtZy9c3QPCS PNjAb87CTEZdGeoLuNqAwEDnY+GMJc+fylLMOqQLsGftvdQ2PbsADR5SVNw29vM68kFV27Wh 8upU+xrY75FrPd+s/D40cRB4XXhBjSMrqJGx5lv9j9Nwb+ogdHZc31x8Qw5025UMiLz/uK2h 5Zk84LkwrmTPuB5XsSotvV/botuJeFD3k/X/8lnb4PamIyI/f8nBVAnhw0Ryqoqyu7xfVqCI bflOdISZHNaosKIbmbuqmKRZgxq6l5z5xw55Y6Ol1e+vhcWeyWsaV4kZae6LKhJapIlDCVll 79yIcrjBOxAasloZkqkQf3H3a0wmS3bUNmjloqqrKArSkxn0JhouqzV4iCUNJ2p2jFGkH9/j 703RLZQVthYgIOhD1LX0yP/s63rXnQLEAXHwQ2jFX1Pbmb43U80R0v1k/rAMZTXsx50402JN RHr0iuIROSbSNwc7cYNss1T9H6GASETSEBCX5qg4BGKW8bqk2kyPutFv1/sfUXzWeHH8s3nw zSpHr+yvp1HV+d80+GfZhj9qMGzv2re1zl8JQFc71m9QImm0+yoFDXkNQ3gMEx01p1e31tNn ud7XV4n45XYXE3HAXGRua2h+/GM5nbtspiJ5GjCLpuwkSirjgP6uzRkRbUd9hFWSJitR/EXt ZDs47sYW04cX3qEcgqqSzQ4SXycBdhflc67kGsUY6dqEzAxV3CVrEZpyeMFGNDu3cvXijsm8 yDzktzCRCPjND4VpJtFODWwgaPrCsbLZkKGwoa5f0k6Pl6NtvLPeRynkukxE5y5lCTMaf5vy L0V1SzmpuHCALDsU+mO/OMmuPj/5NCipb9mvnzi/blnll8WJrNqZEbtlN+Wu1JOBN+GZJIhF aWLCxL3VEYLK2RzQGeZAvagWBhtc2hSt5H7F+Y3eKz7k77V1xO/5vT4LQeu9gMaukPZviUW9 x6mOCqp8fKr3HQPbqbHi/rp99sYpxmAUrDrnNWnN6iO/0u//HVPq8b12rxv8KBynrYY6l3NH oPp+StffBpSSDsabFM2nvneLl+jpnRFEcMcoFpOaAEPcGVa2i+ndNgwgP7IhVfm4BgPUtmyf /2CT08NqAgh4xFYW+MlPz9TD1xXYk7z2f1rHnYAg0IgAmikfUD8HyNDOYCuNr412OVWa4Ig4 nU52FxpsMFCcpL1UH0CNLsHs/LWckjxFW+NKnU9+TSc9ni6NySZnZeQbHmxXBrdE1ZH3560U cM2ecfqulqzRUOzvmEmy7dZPP1bBQ1aZDRx8HQAYsNB9pVqY2zagSAcCgQatJbVzXgr9p2yv wctFhugKSkuWgGu51xUAGKBLXb7wGH3w4+JMqmbcyZTfmsLVbgP61fwRsRFjxX0Z2TAJUtfX 9msOBuG837AXjbopfQKQ9G1OmWYdVyvBbz02D5p6buzaiiWyhGxqSNoNIdECkM47x+dByESy uZ2hujM1eeP13mWWNKN1WO9uCSoqM3PBdhTtAw8cN1kK9M9qRz94/5FxnJXJA/VDYHcIwv17 zoMJQpapQ3uClLu5NArjwISQndkxWRbwMVHCeYgR31UEPfY59x3ah3aq3ZburAfoqGyAhErl wmUjShccPF7wkbEfJ/rT1oxXzeEVwKpy9EUwZL7G1Y0D6sO38endxo4Id8paGDkJ6hNpUHqq Z/3zJ+oLKcu5UMZkXdC9Az++PvMSMXya8YgtF6CoHZRiE9uifGcrJ6nghhIIT3lloQy0gzMr oc2SHEJSEhL/BSRlBCrSZTLJ6r9i1JHDwQ/XyQcKeRKFe7lQCM6XOTSRPv6rm6FgRL7l10BS VP3FeJNoECgGYTi+EhpIy5dapzOdM5aZD0oby8D0Bw3qnKmpAE1KvslBHxhLZAcSWxyy1J9F IKdKztyYaUQh2IVYrRW6/gq2p/N/U0WzDM1UH3j/zzHCMA6Qat/waJMcqzERq8h15EjoFfkO cTDWJFzJ94ySlUVweo6EpclF9jRqteB3BUE7EeYPy+/jHWU5+MpCCHUE/45W8Pef5fSBKAhF mDNhVCZv3bc30XLXGm5pHCYJwTNki16+OmLYvSdX8DR9VIHFcUA5BE/2vTp384+wvoqen2B6 ar6HClBDCGtDaELQwhUItSP/pPTSP1cGJE6YaFNlHNWGCcj1ENEncDld3kgW8cFMig2bmVwx pecKhSbYumo2ojzj94GRr8U3LbUHDI/bDREJDpUMbTUJMkHVm1dqV9cLcPxbjkIT5u8bR0Cb PdvnVWXQ7p+AiEwmxYMC28DSzG9LwUN7XgmwMn4G85PNb7DS/KAweuUidsotoXHTi06S3pn+ 2KW1zQ+xKlM2CutL++KcXcp4dhIXIyGR83KFVG6NrrLJFnq/J5aBV5H8VFAZnZb9eq/daUZW /ryKiwF2NGbRMy8AGoKOYW5VAsFZIz9+1XNNYZdcFId29SB4WuQ3sWN0jyNOE7/iG9KdKKra 6NmRzPNKI4p8UVqBjjq42KEDO5W7PeaWADf0zK4fWCXdozrSy/tUHD+Q57Ap3gEYD4gMq4fJ rbggFUcBV9zm9qv5XXt49QRMOzt+ZbclyzrFiT759Nwpm3JzstcC18pCZZFiMj/TJ2XldlqG xBkwnx6pzl7/GpGy100i3Bk0gnPASQYF8Be5wRZHyNEyP4A6Whd3SQGHyQbi78jbAtCgDPvR R8oCfHyUA55mfWu8PmmD3ws2JZFyXUjeHyrMSOfzO7fBYWGcxt1bMZ/X4Xj0tTCu+tOdJnfE ZSMBPAxw1ZBgGot9hKC0WRemVBPeg7QDMuCl3wlTCF5PJKRNW0qLlsZTns5SP2zWFSYg3zT/ kaFovCfipmIYUdBKiAEU/cKwrHD5Snk+SkO0/mrJ0jIBvFCFkaQ2QL3ETQHecWZUhg/0nJTr FmFny5V32Cmbuc57JSGBAPn8ZPSLwtbQxCh6WBq+gEkJtZALMR8lAanPnWPI7b/JiY94RJCu I8c7g9HiuQ7HV7mgWiB40c3Rv5HdaRlWzWtLkbF3JT8ajjP3IQRJuVCOZP6BiZHPIa83C3Q0 8XIWnYImT6Two7JFIBjzVv65KJyUJigg26hZz8GnwkfnABKNcy6oJhKRJTM1dCqUq5Ir5PVR RqVQW7aOJPfHq+2jVDga5iS6bl0WTOrYtAdZ+BSiEDITMoNftNbkGcaqfzFBQeNs4RRZL5dv N7Wj/1GO/EhRuNSvPzduxaxyjMd5u4HaFo6ZJkZyyckrGsvnvcCQmcvxYUPW0v0zTfDKwBac pM6csH/VgiXWldo7iZhDJxlW1fyqgOtOcAAwh3TTlJu59Yu9woiZiCxUoabUKDRtB0w5PrHr 1GJTXL6qAJ7nDzgTEWJvZ62eDYz5GB0EfB97kdj0OTIOtlbYSO2G/OTHwVbgt6klV138xmyO IXsB0jjU7Pq/QcjCAF8fpeYfdYs0AQhEZl6kut/EpxcwmZTdvv/a9OU4+P3jcTVpi7gZljoD eCdNE+QE0Gt9J5m9c0xtJSvejUyuv+HsEEB+txYxawavUzJfWjeygWVmwcomD+6yaUITuoLm EGuNZ3ihuc3Om2BwoNh6GLhHpVVzNesJa/hT2VsfC38K8TagPeTUcATblOuei+14zgEdSjoP AOSxBO4S/DsHBs9YXChV1rOd19fXOwBQ4UA96TdF7yks0e+fC/VZtEcLWwuJR/ae0peq6ed9 TOQdbG8zL1I1vemzTgWWnuZ7G3k1Gf+SKTl5VI+cf4ukJuh4W++8oe0HWrWL84HQBDtE6Qp+ SMJZALwZl31h2H1tm95OO7YgoHAOsTLKVKr31g/TnkV97Ru7HB3FEDwu+fcFbOJgpvZ+ClpR GgR6JgD/rjj2XnSzDA3/Sk6Rf5b+/0sZNtdDFjVz2DnBksQQqWMRnGg1j9kKwLCpxuG4kTUa 3DdzekfBpw2C9+oDEeNqNAIlq5txBd6MlfOuQ86EXpM8misrwN5GyU8AQhg5CLw+zwWeodwK bWaKqDMYpI9Os5RU1jnw7kxOElL/RFu2Mhznhww8JVzfH/UE2gRSQuQuSAE3A1RrJggc/jMX qIPvxK6TIWHFgP62BQro6+bslosU526JWpAhd0Ywk3gVq94U+tVwvxVFr6tABLOkHu8oOK+D dnO8ToKrRA0ajp5H8nTT4bQfswk/BoCJS4OISmiHsnlLZngkA75o9mQ2FC18R+2zI7qe+mYa NNB07Fy5xDapMla2UEngC78HSM1NyKhx0sXbEJdf9lkNQSqKKj8v0CIlrD7Sb16fcvGeAvOk muA2E1ZrxfRwyD6lbKVpcjtT/tv6dLfm2HFdtQWYCaM/4rRp7AolsptddRzciVXJrgTf2aUv 1VW0+4DwKaB8bjHcC5wqq+EhO1URtB5URy3VoZUZWyeKdJmRL5nKwEBXe/mMpCBRjfe2CRM2 lak/15mJ69DtVWbb9u6P3KkK4VNfQL5+BPU+8F4Bfvb0wdKM9bIjjs6XxFGJ4WQ1aTf8QXGq 9fNxu0/eqdmGaf8LQjUKKJW02RkmzqoqSN3uefmRO4oGgZi+5iCUS08LCki3zjv10FRW8tMy 9WR1SiFSdAzxx73iUd2VWI8dVkUnk5S0wEdDEg+I1sTQKtcwXLExuqWofKF/f+pzCFKdwpAx OUhkwX7q1fXFvN2vy0S/I3Ih6hvsUnxoyEH8UriIUIsAevGqxr60/MGCZJEORuypoxuNDOo1 ZK4kBtNPgKUpAgrz3F400wPVZMKZGDAlWRyE9eqvN1+yTBL48dSdZA5fibd9W4bdVBqurhEs ONG9GNmfiwmxyLSK+8tlaaoDDgdcr8Vj4RMOIZ5rc70Asil85ycOPVmfmS4oylupOeIK0E7S v7158mPs0f/yHowavOQokSaaHQo4D9zpGBJs242gJcfRw3CV65PlaeBJG6L+iiFcaRU1rcTD 5IDDFn90VecmmiFcJnlZ626HEK9RztWN5U2wOlBcoSgXcr6MMdNGKwOAO8r3NdIe13smGrP/ rINpmtNP/oMt6s8x4R7DP1ShFtxN2a3jdLQb4s59UFRDYxZoIbbPJHvHJf4FvhYAgCIYugHg 4sDAz6Y7HOEWMGGAI6weucdf7PG5/1ST6fO9hPLHqLT7YSk/r8dCVEASyFSXGYbt+HuG4777 TXya2pud5EkrLjYo9Ujh4qB2xOseAXwZXVsG4oZJOfvSpbiwyc9ex0ZEKEuAMmkhrj/l3Z7W jpkY0d0YNXYCB8kcI4yH6KgFy3jJch2BSnuWduP9pg707MsEzWYwX1vXNh0GqKcUM6p5QWMz bRunRCtJEgS0tnpizpN+PwdTj6WM2bC5DxJjyIt5YqvAa+HEe2YLbnQTOnepo2ASReULJq/T cEAaFytKTV50YadlVglnMaPYrr/R4l0/dmTrylJKhpsCEAJT1NVNTW4oIhtsRoHRg84fTuH0 WKw6VXWgLRsPdYMj8lBgQZXVoAf3eJgZE8GD9VsI+oeEHEQf3J/WrOyjwSoNUXoGqwGmeX/p aRmxZhmdwmbQQteeAo+f+ZtNz0Gn5WAHeNmeswP1/kXyYkfzqph3pKFzcmcc2Uma1n5wla2m 6Zc2IyVURFU4XkYYsBIh/FbMSMQb0t975hCaY/ZyG/hBFRsJVRGXSWJuAsd39xIi8DR71hF3 2JJLFHnLtJ8/2CiqzkIXsGZa3m+cHQGX7dEVa97moawI8SAuwNg3cskiSGsYx2G+QDUHl7N3 wuYjuvwKxFdQ5rvNR7FnA8otSrBtJsKPQ/yQbgVM8bVKKJ3oAIcJCV4boVYJA+hp45ePs+X7 AQ8qKUi1qSKTub3AqCp4ahbncdULijsnTOkzbEWT9I46bKC3DarPdHagHL2mizdsXoKBxE4B dM7IQrJcY8nMsQss6VxRpkBWPRJZ8RzEpL0UYOtJGabIIZcgFccsvadXdW8yLlLSqg9cS8wB lfPxdY/chFYaZbBBrDVnz8kgC5AkndgnPZvGnx8XQaSt94ZT4ZSODaGx3N5eeYbWRbaZmeWS L9N2Qb4Fiw0gH7p2nL05qxrtXTduabXc0H3BXaI5B2SUHOCvoB9UCvu1mg3uSaIPF15ar4Pu 8RpDHCTPx21rYjb5n7JBUwBvrIGu5D6P8v+tSFPU9txPmc4vdlkv72F3FzJ3+N3tc92fvJqA oiaeYXZTv1yEPsntVwRi0bZrxQPvSRN1paV7LFTW6Air4/Ik5VBTuZkh/SMybnqCrNnu1AKW YE2dKQasq4BeSyOsNxa1x+L9bwFzsWDsJt9XfuPCg8FTTJHbiZhtqPrVxK0EWR/lXjaKF/8u RlGwiEX0zwtZIgF2f8N5xJf1Bvjq+vOEZKDIq/V/TRP54drznaavnUHdHRbVl2dN2SyIjhjY RYyNiV6ax+z5v7GrbcqM1enN2OxXwrhYHowm7/k/L1mqyxW1V5tTJIt8HCrIkqA3WP/mduCB rIXAPIJRAqmEzYSzFgMpm754UKSJ1I1UBem6ratUdnoVz4aX5my4FV5d4Ds7rwj/UDUuLiIf OXUtcfGbChio7dtjnc9DyTzy/c0+R3dw5brbTp4aJHwO9J2ATeGLK3Emp8Zl4iwQzwgJqmpK W5+DlZz9XoOLPgXr5NpYGflw2lj2B7//YLhyBL5PNPwlFVBFzZTawDJf2DYjGkYr2OZWbB/R 0/8Yqf+EtkWwl680eRD1BvTfi8R1sKrcC3cz3qqBZWcnrxB23MEdLoH8MMhZfaj7YvBwKPTI 6MhxS2blgV2PBR8DLyj5sQATfnCzedCH9Mc/EbbViiH6gnyoQxPt6KhKbi8H0H2BnW4Y8pmC krL4BW6luKmBPDFVmP0ukABMvgtdEJbDGVing9vrv3LFvlSxM0s3fwiqmegno6yat5u1STr2 q96UphoBPmS/96ODkquGpqumagMZbR9fg6kZT8CP2O6QQJoDLn3VVNmjSGqC2lTuwiqm2XBN Ime4szpB8MXpv+jVTViMa7AmGZYO7ZEbd4/sw//ef2lb28k6ZZ17AoTGOfwYeTxasvUT+bxo mUJKed7ItaBYqxqCOoaa5bTbRjaZb5XFd/ri2Qc5bvyj4dVNl2sPQErhKlg/9tEXrzrTMQgN u0Jo4URWBuGElWW9c62qbCEcgzUjYuTME3nnwcHHuhsl+Im8Xm0eHIjlVPsYTz/k/eQBPs12 GsePPA6xLmvsgm9fZjIKz+74J7Z8qYX/xi+iE4r0gyW+k45TmN7eWWOKA62x/5etDEsYDphy gZBY923Z995VJkuai/z8xHdFbA09rUEKWeqgJB7OcQvdGgCckZst8m9fOY8vvpsLRBka22an cIxWdBHhra4/guGpe1SFnZ2cjoPy9bAvCPR7dugUskTD+UTpGY14u7TYhnk83IOlUKPQVGsx uaE5ULtoUKl0zYb75yZttLy2jFCy1VNHNhpfHii/hVB0qKJeWqm6IHKZt+vNNMxcGflI5/7z +QEwRT45vl+zNRenfOnodwTiX1WURAn96gRkYJAfFCAZaK2qYJL3v1BDSBvafWY1VMzak0Ga a0PABo4EVqn/+nHs51izG001WQbqIZ+XuUgcrOZiIyD7S0SqAmwTh7G6kd94mtE4mDhkZM4R xc1dUiauRee1wAwCYy4DVSaX4/h7ZbKNGDK2XFvjBuliYNkcNUTYeEaWkBaddw8bCudeE3ur vzj/f2xiu1iTBDMsuCnq1ZIsYus/4tkQLBzmpcBKbQc6hW4kmq1wVEzXx9O3oFAVeQ0yST1r lSh6f/oyc3gs1SofUtPEzZLGvFJF/kKTI7YMOErQsETBSU93DKB3Nhx3a3UeGoL7MKE9ZVRi ZaaOTy3d/tCJ9bDaRBsus6EIZd6tpcNHgAvFyY97+tNjfWPlTuLfPem7GIFhlM1ehuAFabyF oJ/gXxxUwwZ5VobilmeKPJBtTSu7T/auHI2lxa6DTKCclkL1EXveR9FC6uGrlguIYfYOqpfY SKsWfAMxgxlvHJ8suV85azDRwAJRzfm8fv1vOtKNrLb8H6p1zqFgtQdGTVLG0teZhwraiRmW BcJZfti+zQKHO+s+re3Xm64H4HAakVgEBx5TLWUHWF6lDnBcPMTzZ4ZxnZJT0pJD0b+QSvaG jekRO4Aw/vctggvdMjKJyi8gBDjXWAjNhDJdkZac2L5xdy21bRvtc1/EcPs58OyD15pSC8g4 MmJyI3WvGi9y1WVfDTkbbBKvzJJkO3TMqz8jdEc9stON2BlmeXerR5pZYSl51mi2Veqo+Bpv 7p+mvW1W7XaDvDTGupznecUGQM5MIIQRG+vU+4kJtoaBjT1SY5OLYJPpsd9w8djstMbKlp4R atUXSNXi9QlkTr2XOJbMiHEokbbDmmC4HG5eD/Nvb5PRBxSit4QYfGba/2Z2+50TYOoLE2pr MTp+OmI26UVn8oON7xEW75H5a9a2RZxBzzH3J1Lw9wufQVB26EZmeaQRq1cBmN17wsgGRuR4 YsLRffpCkm71OADEKXj93EtB99eAJGKpJFzFZvhHukSZQHYBoKaJ0+v0pzJrfciJpTEdpBnn vL5s9IDe38nqBwJvxB6WdFYt5+JBWxUKqJtIqv6rx2Fm64gHhK1VptzF60OUhUt+5BxBqktm kUnCPNcQ/BlOhicRwIarZTp5GrC/X22jT7UqUwkAdhmqyDbPUKotOgTrBY7Z1auwCcOyaYK2 Tue3+Q6l/eMDi/AEl7n3dguVKSFIjdGJfmu5lM8tXmLf3yvRFs15kzXkbRaJeuW5EmZK259w vcefYpqvnO97y0K0rAH77J5uRFGSFFJfMpvKF/tpl4kalUg9aVXwL9QOmUbezppx3pvWWvUZ h/ED8w1JcEtzaxTxD2YnquP5vTtP07koQjcIKB2KIRY+FX+FZ4ta0AakpLRd60Z4iTWBs1Qj WfzmxGLpMU01inE3R8MTPYopXgI3sNwKlZ3XlSDZegTc6ObvL105qQ5hdMYV/c0qcNtYbbtY m+iDmi1WNkeHHpA2pujf0MPCg69gEz2vytzqEquRAkiE5ywobql3frZlmf+ZAlA4coKxTDUh V2PYM2Ul9opZ8xywvV1CGzhB/RKuwj8Z37J7yykFtCHkYtK+U2Um5AbC1uU0rGDn+OPrfJR4 Q/pMR5MoqusEzfGfVG+itRFDq00vB5wvGzN5yBYK7Kn+zC6q83Jua5VzHBfYQ44g0Ip1KQhD 6LVoyaMtzCaTaEvFnB6tzZG+xPdCK+iTBuInAZ/K5q+OPkcLxwJSjQSuXkIZFEWiYDUDNNvx t+rogajwBjj9HQQCaMXI1XMaK32KNpL+bMW8NhUoQe5HXhCxu6IMr+VeKGWGS+bR0rLEQj92 48oe3bRZeel6e/m4SurGgudo9sba2lRwJxjja0gLFr65JnEY4uLN9mXDtk9ki2PwLE9l552B jJhKeabGvrIh/S6EITz4yXaPgg1XTut+i+mp0NM9fYOJ5V9WzSPaT262lwBrJ1fvM7o6DTS+ J6+Jei2OxEn6cMUOIUXlTZXNZ5SSQ+LdSpFJskSyvgsFucOz4lvYlAfJKXYR8x8i2jc79aB5 wNP4JPRySg+BWjodkLq+bkMEIHujsalYJwo9QWwHODurNJAplICZ/T9yAtsC1+NpLFpfrtJm NJouPUM/l8vS+PbvKxsQv/w0F5jrn7P/4sMHH+OQJRCAFGydo6BTyMhrN9Dlz3tfLhHZ3aZ+ sCsvuZXjnLZrZ4Um/cQwh6hizE0bSxGDnShujN/TzxGdigyrMvN3aDNGhnfXPj/uIrfwn6Lv pDRXQ1rI2U9pgtu2G33CKgHHymprdSWdwkUIK5xbIrG/uKFA8IQE6gMrDoi8djPgGrnkksI1 zYx4LiffqBd9jdNICmCqEZt+cJGP1a5QR2KJ6bozmfdsRGTJQoT8vBIk5ABuG1tHh5keKCxC 3gsv7dIHnHOGhng1zHIzGngu0dA9QgKiEWTWm5Y+xnqXx4if7mVqgZDcUAiFnYbJnxXpOVtf x46KBqjpM0Ly+7WuBh05xSqwUTiDTcedWXYz6YkR1v8ycdbkwaWGAEAtzEhkZL+Dt63KCbL3 mcuhAAZlTuEcUbBlLn9WP4URS7TUhXyVJKZE8K5gF0u9thn/dogOSQU0hUJneHrTMbOTLj/z /9536xmAFgMfX1og90IBI/AtmqNSm0UdihNLWBymZ3o0s9ISaDmer7kwDPPud9fxZeWwAjwr 5qKSwU4vy9JBJjQfO07TA78xq5pO+d1D3G6oaXv8PUfwUnSmYVS2V7vtjpYiyLF1cwOUlhir pNLPCPBML2bT8bQxdRwPdGD3HsrZWKtUdAuo1oAWJPqq4KlBa+HNnhkRXXU9mTfJXcHjz2GW tZiwsG6FdjXhNxdLS6DYIPChaDBN0OPj4vhO/xx/6VfcAXcsDVSEqCgm54RcirGNOmTuIf2b X12Ble1kNMdXfZzDlpTljaN+6G89F2baRBbRHCb7ScnPl73c+gZLs4I4P444tyO13QurFrF2 J0bhwo/j9PA+3VaVq4hun2RuziPHcckK7KteqGqR/fJZ5jlcB6P4JiookPPe8UBWTRVLPAs4 MLRfpI7ztfzMsd4gmTBTjm18mkqqazKYY8/eEcDj1l69DfsLrDyNnf/lYXInC+dkvH5svWgD A22UGFLfTuHB26lz5JK3Z7gI6Kkpssq2+fNc5qngpaBX1p1a75hjPT3abZ1YChgHH5qzenJS IcbIKgtDJrIi7w2ytmk+wZM2gZfTMPk74OWJyHsNMrtmdjkBIcoJ+2537c2ByC5Xow5RHaHD xw+6eD8Dlnwz8PrnGbjbArceThBz35M1V6kY3BMHZwBTwqmbJ6LDlHK70TSukrM0tsAadJYZ C1DfHuvxwdvEAQsS5RV2Lew2EPtWUKhx1PXktWeI99FzlDu4fgQJN58DFpytCeACL5M9Ce6v gT/q3d7AxdKoghaM8Kz0pSc3ABALholIeKKjGPc11maC5wN6YqG3L/b1WE+Ir+vBA5mBIUM2 raGRciA18cTN220uBOVCt3qTorvDQebSydcy4zuax0cnqvwfQwfqbzhfataSiObOKUC318fZ rDVteWOEYqpuUYlVkWBJBx3omEY+348eAhrgVtqpAJJsgpl8q7MK9q+1dIw6ufg9o1szmNV2 1YB7OVwZjOnvIkLQZJjrAD9Gq5OiMEEMVlrJ5cjU80g/Tc3crdKHNfCPZk1hrROsG+75h8lz Y4HtO3Bnu5ACHYxdSSsp2IDKEsTT1qClbqDhMFkY2gxhDsc/LKWSGn8S4/0VBiTzPZBZeY3E eo0e6oS6TZxmdV2liC/L4SGHybtYteUxL3dH+vRIAl0G2rLA+Emd0qJwYjImQTlesj1JdaNW d1yCXJ/nS6jUTInOkxyhRsSuERwN5iF7cLWYZN98yjuQT7EjHd+2BfVV/HFVGtrEMT8pyPPZ aeevd6sn7WAekK1nTvXXrXWIU0qKxo7p3RLraxCAIfQmvBB/yxMsl0qRIIj5xsRJehhLN2xH r7EgbuKVgP+cJFDprzkJnJFOOVL+clODZ3oiFN6QGmnBxvAw4PVI2FrYXRDsc4Le8CYeUosg LFgTwgZIq50sN/qb90fOCGfoE9iPoYxI9rDYldrLwaH02Bt+y11E+FXzFUIFn7FWTjybSqF1 eJfEWjEDmrJWaHCR8Vg2WeFPhqo1ltKU97CXE0iT/yMmC+S2Hn4XRKqW/EVfX3U1tpp0yuFI u/3Oit9x+8Sc42wQW7WIispp7XLed5yOKYgyAjVvSZ7cPK5mR2eEeiMKzVmNJgi+l+jIWaRf oeihklYhje8DOOFE+mgEfBDEDNs8C2AUgJvrvWtp4rxeen1K5W4tjxlgBuoUD6gHo4TLePRk mmm9Bz6trCJX7byO/9hsl1Gqb9tUR2i0O89OTsYmJo2s96qbn7q9l3BzQblZ+aeO2N7m07pc AGb1znduCRW28EKaWzf9owpB147g3kYmd0ZboUC54vYtvBh55f+9LeaCUeJuuQSwXFUDXZl6 gVq6NmJ10LWcECNTAvZxFwltJcrKLi9kShexxwX2o/rKr1s0lA2wp/20dxHZ3Wd6Uyx0w2Ov GsNg3OR588m2EHm/shOsHqxZU/kl5MIBLTETetcLCxMPBPSo1Ysi7pYuF9F4E+sJ0hQJYgCs TXa2ma7wuVL8GHlPIiQQr5iHdxbFo+n5U+h3A2XZm8obBhIEo+eyH8HgG4cqK+JoKtUWD/c7 GTU2BbKgEae5xbTLNgGk9KBSFjS20lhYWnh6xy2Hy955p8R4p+JopnNZ1SizI4I4Rx+pp5Rh BHIiHDZaC3AFEHCGZXaxLCF3WH7v7vKjl+4OzUMg1xkOj0hhG6zD3agO/oIeCQXEFkVchyNK TObWIOC9V/E4EwYpzYrHQx+ctLWYjjDxqJSekpXhd6hPsP+j0znfXrtkzv2k4oUYyuRiacbb k6QtBBfNArxK/u7SHjScJQduEEtvw5XaWezB+VJE8lUNLTlHLB8bdltw4XXo/Z2JPLESL5xp 2faqgk0YD2tNwOWD/FddqFut1Ijlky+XmY7UIqcuGe8Ti8rha2w6XLl4IJpcNAvCr2c8fe3e u6ETFerUP8gXBj/oDWlLigY3cUdx4QIKFrSx97ptqzU0zevCWbNqmDZDgSGVQLLSEpmtgQsu ltt0YeGSEd34jVcaV0h9hk6lc9Nxm2bjPlNsdHziG2EogO2JUJ7GrBdNprIarKNtBIP+p7dP +/UnqsJ/E4s2bugBpgx88WikCLKIVRJ+YMg3GVfz5JSQJFlO14zWCkg4ADejzA5wnYRT6OVy Q/sN5EYTK6rgbZQklr3AgWnUmf8rJ9bXxJN8aRZbZzn0yRTKZ+vW5DtrDV577YaUzXueFa8v o5+0s+kEWaYGKoPaXWQJXx03V510CyAC0CVZlBSin6yWiHWcG09LYh4j4eWKCwGD8BkfZGFS m2J0U66dLOAcPlwy4uqpJzG5pMMCzHvBDf5qerzdzT21CFotDSqVkJ8P5cBfYipEI/WxJxgV nLjYKMAAn2O9jZ/kNzISpk0H0ev9XmzkXZYfjmoxaMiGCvevZvdPJmedmtVQlNdym67RCm0f 84svm/8kQf7fRd7Pl+L/kX41xfi50HWBmOhhYfr//Z1YNju0V0mbvtQ8epHUpys6T+bhhyhE eFZOlATmk3BzJHAnR0c3Wj11ucqMxk8ZDIjL0weC72xcqYNZCkX36cF5sBGSP+VVfQK8LZ1D 12NPgbxaimv400Y47JZJBi6NkxRnimZAXaUMKadl1TlY3M0jJJ18xB23sYmtIFyfalUx5yQF Wbpw+Y6Bl61MW1WoQdduxacB6PpNdo399mmSw+75DPi9jdAKbXaxYrRJMqLf1eQwD1kxRvKZ NHwuWhMrEDVsD3kb7oCSPyqKt+xqoGKI9YMOxjd9kGFDQqLnXL6yaQx5+vvmdSwzMAEndUoT nrCno+fgYpaU90c3Nru61xeBb3ZWa4tznkEoBwcENwfgta0FPlnYLexPygTCxziG3O4etGAY u1nLQrfcFWz+rQ2pBFbyr9KoeVuxLnnSanb2sQ7elHJ42UythshkPZbps3rgQ3LEWEZIKV/w Rb06472T/vEwqgcoG6d8nrysfRntOW18QlsY3RaKiAyCIzKMSzK/squG8ULArCyY6xBsIyse Qu0ZMUngsiEO3HlaXjOd8VIUrbMrTkv2DZYZzlilfINOikhLiTkeg6tk4JE+EmJVrrnJv43j X3eqjN+/94dY6CF3GrGVYOzq76RCzak4PGi96F1czWztmNSB93TJeJvsXsshUuwgijaw+NEb MLwMVeJH+IaEHkVDwzqk7BEzYDHB5e5i09RU4IGNhTMBIz6BYqehtVOmRD7iWW3NscS2H+61 YhOTIQ4v7XN/wU/V5KBQzmAR3ZzWjOGYqh58USzFHEJIdkXwKIXHKnOtM2XP7WGDLtLjaOKh VxGQkn3ziBhdop8cj/xqj9/uSzjTRSRlhK2tcti9+4+YUATxpXOKBqJtQCnNoZ4E+yLd+O0G VWlTuA34an2dEW0HGHKWt2sdXNXm5dhZY4GQDkWFdxT2hozoickk1m72wRgby7aJ3iMxluiO AsO0Z5i1EgO6I1oz3f+tE0ryO80dsB0NT37g5YDyvERWpTiMpTGyacQZTqf35pcfSVp7CdAD 4tXTk+cnuiFXXcEQVZGJJjy12Bo1IYyjFxV0aDaBUOfdhuIOiCyybMrT37+qD7hIp2v0/aAs 7ziu4teg6NVlv5H/JoN22xO29ZVJKX2iCk6IkjK3nyu+H7YxafUQyl6Z2Zin/lYwazdH6L28 GtOTk6JRThqy4FtOIG/9xBEv5NTZtWbx+qmVdFQpY/chHU3mZnjresOY5zSywc6OobtPJdr7 yQH46CUmIDG8CHFQWZOy665x1KC5KfIzaYpIDOR4D+UCq7dJoik4yCbPhQSt0l4ii3L/fHiw +MTp7uPWWvK6bwRQL7P7ktg2LIHNpIm9jglz8tlWh6dV1qCAwUJD8a1e4jwRWXIc+LpY+zJE 8/Y6sYgrjouJnWv9RL0xia8jqCm8PaED/XGAScCcQ6QSUllrTUGRpvwAbSOIJRDHWsL3je58 TCEHgddrRxMVXUen0VUAXO5to3zogOaYoomWHS+RFCKiDWrqGXMIKvyL0IgQLVP55XTB2AEM bD/YjqJHAS0S9umwuvvOLPHmizKXcAlBKS/a091MpKHCvEPumj7ZfVy3HZ44+K6P+wVdvWYa Z4hQtNtVBzvmSXREhuquf0fvR+TNGEuCqbtiWrMz5T5uk4wvjsZh68ZePlQx3+9kclBn7sFo 7Kdeh2cZaV9cPSpMTqyvC+twRiwZ4/bZngztRvhTcyeG8Yqr3lYK4jGT3ghphMLuQtQGQpol xeW8N83KgUxys0yvPHWTfD0GBdP5FaIYV822czhPS/6pbxXgWnBFJ1rmszg5lYNsMnH9KcAY 96BH8hYCJZIAB/cA0YIYf8NYU1r24+q191pQbi2R/sNpTtMQEYLnzu2c/byFtIcHxmPhMO/t dcBnlLb9ubWoHaamDwsutrvcQb+aI/4JecW+uFg9CKD8M3dD00XesF5CAKGE/YkMR8fcNF2R zhpg1HzJIVvA6HtFDjdzKkfJQlV7g1LS6JVZ7t18wozn1JpvuN1A5vEqWsROqazWek0zDNmw 5JCyWDvnkoeT2Z8g60gZOsZgiBzYVZqX9gD9m9N8kqrfbYbOgWASvqVe4CvxxTrTlkx8P6FN GR5I9Y9Llnks2w5JPdb97WJSg/TX6ERgs9E8wcFyncSqBI8WLDCs3cmp3x56tI/66EpdNDBW Bwp2zx5y/fzE+s+7hWCAThQ4cnq8T9ZQzvfxPbDkTY+9ocSmm3lkBf0/SfV4+q+jMpagHWnv +jy9MyoeRGucrQ8tvWRY9tbCEbeMAv0noeoamhruvQnMW/jODOGmOdWjKdT04KYk+S0IpnaA LIxsxy5IqqaOCp6S0PIRxknixcdA3ga2Cl7xR+OzN3Mo81KsWB+0iE4VCddvSXKfhotGcnc6 KuruYA/hp1DjVbM22UQ8KTPIxaVS5fFadycTiC9fffeczb0LkKgIerCteuV4aHP0245NBv5e uaju6dLb2Hq/r7bEpBEJhimc1SYt+bH9944o/RD6QA9ALh2SZLYLYw1QFpedAEMi7oUhgwA3 GEgOW/iqLHw5fAERgaTRMxgr2hGlZLlVFolNQD0PJadRnlaXT5x9kgtpTE9QT/XNoVl065TA jsOxzcXhHPeez8kKatt5gv239hrFZP18LaSSgS5XSlKGzNPW9FYBWtQyL56CWBMS71fV7Bzb dJkG9F0WusB6/tyRY4UMizdNZU4qkTEZrYfW9y52Uno1AkcsSpLtCqAH7vMWC5CGu2qejNrE K2a7aSg/8PaoM0yNvrgNeNWq5RbAlZb0wjxTlEkdTkfcepRLN+9Z/iA9R5DuUBiv5Ksfg3DX Nfjyv//G4mcy1ideDKZdmxGBNJnj0RAsEwf+8Q+mJvnelkGcw/G924Dv9K6r+15QMBtQSwEC FAAKAAEAAACgfHMwFRtw5Z9QAACTUAAACQAAAAAAAAABACAAAAAAAAAAZ3dwYmcuZXhlUEsF BgAAAAABAAEANwAAAMZQAAAAAA== ----------qymqgdylthraiviljgnu-- From Renata Maria Dart Sat Mar 20 00:15:04 2004 From: Renata Maria Dart (Renata Maria Dart) Date: Fri, 19 Mar 2004 16:15:04 -0800 (PST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 Message-ID: <0HUU00G1AM14IW@mailbox.slac.stanford.edu> Hi Derrick, >> So, I did a ctl-C to stop it. At this point the fileserver process >> jumped up to use 100% of of one of our cpus (there are 2 on a 280R). >> I noticed that there was still a salvage-tmp process in the output >> of bos status and there were 2 salvage processes running. So, I did >> a bos shutdown of salvage-tmp. But, the salvage processes continued >> to run, accumulating no cpu time. So I killed these 2 processes. >> But the fileserver continued to take all of one cpu. Top showed >> it to be all in user, very little in kernel. While the fileserver >> was using so much cpu, no vos commands would complete. >> >> I ended up doing a bos shutdown, which responded quickly and cleanly. >> I upgraded to 1.2.11 and rebooted the system. > >no guesses on this one, either, at least not without more information. > I do have 3 runs of showProcInfo for the high cpu fileserver situation. Would they be of any help? >> Does anyone have any ideas about the .gconf lock file being unremovable >> after a fileserver crash? Should that hard link be there in a normal > >*if* the problem is caused by a fileserver restart (crash would be a >subset of that) perhaps it would make sense. peoploe have reported this >problem without a fileserver crash and i didn't think of "did the >fileserver restart". > >basically, a reproducible test case would go miles towards finding an >answer. I think there are two .gconf lock file issues going on. The one is where a gnome user finds a lock file that needs to be removed before they can launch their gnome session, they remove the lock file, and then they can proceed. We have been experiencing that for some time now and we haven't seen any obvious connection with an event that might cause it. The other more recent .gconf problem that we have been seeing concerns the same lock file that needs to be removed before the user can launch a gnome session, but in this new case the lock file can't be removed unless the users home directory is salvaged. This latest problem seems to be connected with unclean fileserver restarts. Then, in addition, when we bos salvage to fix the unremovable lock, on at least two occasions the bos salvage has run amok and refused to complete as I described in my previous mail....with the unpleasant side-effect of the high cpu usage by the fileserver and consequent loss of vos capability. Thanks for dealing with my lengthy email, Renata > >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info Renata Dart | renata@SLAC.Stanford.edu Stanford Linear Accelerator Center | 2575 Sand Hill Road, MS 97 | (650) 926-2848 (office) Stanford, California 94025 | (650) 926-3329 (fax) From shadow@dementia.org Sat Mar 20 00:31:43 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 19 Mar 2004 19:31:43 -0500 (EST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 In-Reply-To: <0HUU00G1AM14IW@mailbox.slac.stanford.edu> References: <0HUU00G1AM14IW@mailbox.slac.stanford.edu> Message-ID: On Fri, 19 Mar 2004, Renata Maria Dart wrote: > >> was using so much cpu, no vos commands would complete. > >> > >> I ended up doing a bos shutdown, which responded quickly and cleanly. > >> I upgraded to 1.2.11 and rebooted the system. > > > >no guesses on this one, either, at least not without more information. > > > > I do have 3 runs of showProcInfo for the high cpu fileserver situation. > Would they be of any help? Probably not much, if at all. > >*if* the problem is caused by a fileserver restart (crash would be a > >subset of that) perhaps it would make sense. peoploe have reported this > >problem without a fileserver crash and i didn't think of "did the > >fileserver restart". > > > >basically, a reproducible test case would go miles towards finding an > >answer. > > I think there are two .gconf lock file issues going on. The one is where > a gnome user finds a lock file that needs to be removed before they can > launch their gnome session, they remove the lock file, and then they can > proceed. We have been experiencing that for some time now and we haven't > seen any obvious connection with an event that might cause it. The other That's not an AFS problem and isn't the one i'm talking about. > more recent .gconf problem that we have been seeing concerns the same lock > file that needs to be removed before the user can launch a gnome session, > but in this new case the lock file can't be removed unless the users home > directory is salvaged. This latest problem seems to be connected with > unclean fileserver restarts. Yes. And I'm still looking for a simple test case on this one. (And I don't think it's "unclean" so much as "fileserver restarts", but I'm guessing) From jaltman@columbia.edu Sat Mar 20 02:08:38 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 19 Mar 2004 21:08:38 -0500 Subject: [OpenAFS] New OpenAFS Windows test build - please test Message-ID: <405BA7A6.5040201@columbia.edu> if you were experiencing problems with the 1.3.60 release, please test the 20040319 build located at http://web.mit.edu/~jaltman/Public/OpenAFS/ /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/ Thanks. Jeffrey Altman From tim@umbc.edu Sat Mar 20 04:22:41 2004 From: tim@umbc.edu (Tim C.) Date: Fri, 19 Mar 2004 23:22:41 -0500 (EST) Subject: [OpenAFS] New OpenAFS Windows test build - please test In-Reply-To: <405BA7A6.5040201@columbia.edu> References: <405BA7A6.5040201@columbia.edu> Message-ID: > if you were experiencing problems with the 1.3.60 release, please > test the 20040319 build located at > > http://web.mit.edu/~jaltman/Public/OpenAFS/ > /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/ > Just installed it, and it looks better. Before I was unable to see anything in the afs root. Now I am able to see stuff, yay! :) A few problems though... On the Control Center, the Drive letter's tab seems to "have issues". Anytime I click on it, it seems to go haywire, and really not be usable. I can "net use" to get the \\afs\all mounted to a letter. At first I could only see my cell(umbc.edu) when doing a dir in the \\afs\all drive. Then I could see one other that is kinda shared at our site. I did check the "use afsdb" while installing. I checked, and there are a bunch of cells in the listing under advanced. And our root.afs does contain more than just those two cells. Looking better though. :) Tim ----------------------------------------------------------------------- Tim Craig These are my opinions and not my employers. :) OIT-Systems tim@umbc.edu It's hard to be serious when you're naked. - Garfield ----------------------------------------------------------------------- From jaltman@columbia.edu Sat Mar 20 06:03:37 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sat, 20 Mar 2004 01:03:37 -0500 Subject: [OpenAFS] New OpenAFS Windows test build - please test In-Reply-To: References: <405BA7A6.5040201@columbia.edu> Message-ID: <405BDEB9.7080207@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms000302010000070904000104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When using Freelance mode you will not see cells until you attempt to access them. This is not unexpected. Please try to describe what you mean by the "drive letters" tab going haywire in a form which will allow me to attempt to reproduce it. Jeffrey Altman Tim C. wrote: >>if you were experiencing problems with the 1.3.60 release, please >>test the 20040319 build located at >> >> http://web.mit.edu/~jaltman/Public/OpenAFS/ >> /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/ >> >> > Just installed it, and it looks better. Before I was unable to see >anything in the afs root. Now I am able to see stuff, yay! :) > > A few problems though... > >On the Control Center, the Drive letter's tab seems to "have issues". >Anytime I click on it, it seems to go haywire, and really not be usable. >I can "net use" to get the \\afs\all mounted to a letter. > >At first I could only see my cell(umbc.edu) when doing a dir in the >\\afs\all drive. Then I could see one other that is kinda shared at our >site. I did check the "use afsdb" while installing. I checked, and >there are a bunch of cells in the listing under advanced. And our >root.afs does contain more than just those two cells. > >Looking better though. :) > >Tim > >----------------------------------------------------------------------- >Tim Craig These are my opinions and not my employers. :) >OIT-Systems >tim@umbc.edu It's hard to be serious when you're > naked. - Garfield >----------------------------------------------------------------------- > --------------ms000302010000070904000104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyMDA2MDMzN1owIwYJKoZIhvcNAQkEMRYEFG3yL9NK7WVn Sq4280IQwe/2jAs1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEALvg3GlemCSeD11pIzCRig9nxGqfA msGH+GXPK8sxMz8bvGmB24C2kJ0/c+Yu9x1MNAYsnd/fowAgV4ts/7TZndPp/yBrvMgJMd/P 6gmQ3sGbkHKRbEDlVGqa5KQcQPyOKJIqJF/h9cgLlJziDks7VQhIai4t2Lcdz/dULqsNMNun 1Gdl7hRkFKEp9ZU/UDz/PUftIRGTUHdwhtvYcx7gbMJnWR1p2M+ng0UOHhctY+WNXa/kexWt vWRjDTEJT/OdR2m9nsAxRsmEcKeq7KtMJW92McsWvA/fNXNcHlUw71yKaQYhriGJP6dJfct+ d/gnXSJ/p+4xZKgL1YdfXc/c8AAAAAAAAA== --------------ms000302010000070904000104-- From jnurmi@qwe.cc Fri Mar 19 18:21:09 2004 From: jnurmi@qwe.cc (James D. Nurmi) Date: Fri, 19 Mar 2004 13:21:09 -0500 Subject: [OpenAFS] Kerberos troubles... (addl) In-Reply-To: <1079718027.18012.37.camel@qwe.cc> References: <1079718027.18012.37.camel@qwe.cc> Message-ID: <1079720469.18012.48.camel@qwe.cc> (In response to a question I'm sure to recieve, since when I poked around the archives, it mentioned the domain_realm section, but from what I can see, It looks to be right. I've removed references to my work machines, but modified nothing else. kinit works perfectly either way for both realms) After poking around and doing an aklog -d, it's convinced that I should be in the kerberos realm CC, even though kinit works fine w/ the setup I've got. (Adelphia is my (home) ISP, QWE.CC is my home realm, qwe.cc is my home machine and the previous references to michelangelo are simply CNames to qwe.cc proper, the same machine) . Relevant krb5.conf pasted below: [libdefaults] default_realm = QWE.CC # The following krb5.conf variables are only for MIT Kerberos. krb4_config = /etc/krb.conf krb4_realms = /etc/krb.realms dns_lookup_realm = false kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true # The following encryption type specification will be used by MIT Kerberos # if uncommented. In general, the defaults in the MIT Kerberos code # are correct and overriding these specifications only serves to disable # new encryption types as they are added, creating interoperability problems. # default_tgs_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cb c-crc des-cbc-md5 # default_tkt_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cb c-crc des-cbc-md5 #permitted_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des -cbc-md5 # The following libdefaults parameters are only for Heimdal Kerberos. v4_instance_resolve = false v4_name_convert = { host = { rcmd = host ftp = ftp } plain = { something = something-else } } [realms] QWE.CC = { # kdc = qwe.cc admin_server = qwe.cc } [domain_realm] .qwe.cc = QWE.CC qwe.cc = QWE.CC .adelphia.net = QWE.CC adelphia.net = QWE.CC [login] krb4_convert = true krb4_get_tickets = true [logging] kdc = FILE:/var/log/kerberos/krb5kdc.log admin_server = FILE:/var/log/kerberos/kadmin.log default = FILE:/var/log/kerberos/kerberos.log From dgm+@pitt.edu Sat Mar 20 17:02:39 2004 From: dgm+@pitt.edu (Dave McMurtrie) Date: Sat, 20 Mar 2004 12:02:39 -0500 (EST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 In-Reply-To: References: <0HUU00G1AM14IW@mailbox.slac.stanford.edu> Message-ID: On Fri, 19 Mar 2004, Derrick J Brashear wrote: > > more recent .gconf problem that we have been seeing concerns the same lock > > file that needs to be removed before the user can launch a gnome session, > > but in this new case the lock file can't be removed unless the users home > > directory is salvaged. This latest problem seems to be connected with > > unclean fileserver restarts. > > Yes. And I'm still looking for a simple test case on this one. > (And I don't think it's "unclean" so much as "fileserver restarts", but > I'm guessing) fwiw, I spent countless hours trying to write a reproducible test case for the gconf issue. I used code that I ripped directly from gconf. The plan was to be able to use cmdebug in conjunction with my program that could reproduce this problem. Despite many hours of trying, I only managed to reproduce the problem once and didn't have debugging turned on in the cache manager. I've since given up. I think Derrick hit the nail right on the head with, "run gconf on multiple machines and pray". Thanks, Dave -- Dave McMurtrie, Systems Programmer University of Pittsburgh Computing Services and Systems Development, Development Services -- UNIX and VMS Services 717P Cathedral of Learning (412)-624-6413 PGP/GPG Key: http://www.pitt.edu/~dgm/gpgkey.asc.txt From shadow@dementia.org Sat Mar 20 17:07:52 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Sat, 20 Mar 2004 12:07:52 -0500 (EST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 In-Reply-To: References: <0HUU00G1AM14IW@mailbox.slac.stanford.edu> Message-ID: On Sat, 20 Mar 2004, Dave McMurtrie wrote: > > Yes. And I'm still looking for a simple test case on this one. > > (And I don't think it's "unclean" so much as "fileserver restarts", but > > I'm guessing) > > fwiw, I spent countless hours trying to write a reproducible test case for > the gconf issue. I used code that I ripped directly from gconf. The plan > was to be able to use cmdebug in conjunction with my program that could > reproduce this problem. Despite many hours of trying, I only managed to > reproduce the problem once and didn't have debugging turned on in the > cache manager. I've since given up. > > I think Derrick hit the nail right on the head with, "run gconf on > multiple machines and pray". Well, I think maybe the key fact we just learned is a fileserver restart is involved. Are you willing (do you have time) to try that test case if I give you a fileserver you can knock over? From jaltman@columbia.edu Sat Mar 20 19:35:48 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sat, 20 Mar 2004 14:35:48 -0500 Subject: [OpenAFS] New OpenAFS Windows test build - please test In-Reply-To: <405BA7A6.5040201@columbia.edu> References: <405BA7A6.5040201@columbia.edu> Message-ID: <405C9D14.5020600@columbia.edu> Jeffrey Altman wrote: > if you were experiencing problems with the 1.3.60 release, please > test the 20040319 build located at > > http://web.mit.edu/~jaltman/Public/OpenAFS/ > /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/ > I have once again refreshed the installers now dated 20040320. These builds address the following problems with the 1.3.60 release: * runaway thread in afscreds.exe results in slow performance * ShowTrayIcon setting in afsconfig.exe does not work * Stopping the AFS Client Service results in afsd_service.exe crashing * "fs setserverprefs" when called multiple times results in the AFS Client Service becoming unresponsive. * The installer now makes the choice of whether or not to use DNS for Cell Lookups optional. Once again please test. From deengert@anl.gov Sat Mar 20 19:43:27 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Sat, 20 Mar 2004 13:43:27 -0600 Subject: [OpenAFS] Kerberos troubles... (addl) References: <1079718027.18012.37.camel@qwe.cc> <1079720469.18012.48.camel@qwe.cc> Message-ID: <405C9EDF.4FFB260C@anl.gov> "James D. Nurmi" wrote: > > (In response to a question I'm sure to recieve, since when I poked around > the archives, it mentioned the domain_realm section, but from what I can see, > It looks to be right. I've removed references to my work machines, but modified > nothing else. kinit works perfectly either way for both realms) > > After poking around and doing an aklog -d, it's convinced that I should > be in the kerberos realm CC, You as the user are in the realm QWE.CC as you said kinit works. aklog is trying to get a ticket for the AFS cell and needs to contact the realm of the cell. What is the name of the cell? What is the name of the server with the cell? What is the output of aklog -d? ? even though kinit works fine w/ the setup > I've got. (Adelphia is my (home) ISP, QWE.CC is > my home realm, qwe.cc is my home machine and the previous references to > michelangelo are simply CNames to qwe.cc proper, the same machine) . > > Relevant krb5.conf pasted below: > > [libdefaults] > default_realm = QWE.CC > # The following krb5.conf variables are only for MIT Kerberos. > krb4_config = /etc/krb.conf > krb4_realms = /etc/krb.realms > dns_lookup_realm = false > kdc_timesync = 1 > ccache_type = 4 > forwardable = true > proxiable = true > # The following encryption type specification will be used by MIT > Kerberos > # if uncommented. In general, the defaults in the MIT Kerberos code > # are correct and overriding these specifications only serves to disable > # new encryption types as they are added, creating interoperability > problems. > # default_tgs_enctypes = aes256-cts arcfour-hmac-md5 > des3-hmac-sha1 des-cb > c-crc des-cbc-md5 > # default_tkt_enctypes = aes256-cts arcfour-hmac-md5 > des3-hmac-sha1 des-cb > c-crc des-cbc-md5 > #permitted_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 > des-cbc-crc des > -cbc-md5 > > # The following libdefaults parameters are only for Heimdal Kerberos. > v4_instance_resolve = false > v4_name_convert = { > host = { > rcmd = host > ftp = ftp > } > plain = { > something = something-else > } > } > > [realms] > QWE.CC = { > # kdc = qwe.cc > admin_server = qwe.cc > } > > [domain_realm] > .qwe.cc = QWE.CC > qwe.cc = QWE.CC > .adelphia.net = QWE.CC > adelphia.net = QWE.CC > [login] > krb4_convert = true > krb4_get_tickets = true > > [logging] > kdc = FILE:/var/log/kerberos/krb5kdc.log > admin_server = FILE:/var/log/kerberos/kadmin.log > default = FILE:/var/log/kerberos/kerberos.log > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jnurmi-openafs-info@qwe.cc Sat Mar 20 20:17:48 2004 From: jnurmi-openafs-info@qwe.cc (J. D. Nurmi) Date: Sat, 20 Mar 2004 15:17:48 -0500 Subject: [OpenAFS] Kerberos troubles... (addl) In-Reply-To: <405C9EDF.4FFB260C@anl.gov> References: <1079718027.18012.37.camel@qwe.cc> <1079720469.18012.48.camel@qwe.cc> <405C9EDF.4FFB260C@anl.gov> Message-ID: <1079813868.4737.26.camel@qwe.cc> [[ Hah, I knew these were coming 2 secs after i sent it, but i didnt want to flood the list :) ]] here's the basic output: Script started on Sat Mar 20 14:52:48 2004 jnurmi@michelangelo:~$ kdestroy jnurmi@michelangelo:~$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000) Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached jnurmi@michelangelo:~$ kinit Password for jnurmi@QWE.CC: jnurmi@michelangelo:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: jnurmi@QWE.CC Valid starting Expires Service principal 03/20/04 14:53:11 03/21/04 00:53:08 krbtgt/QWE.CC@QWE.CC Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached jnurmi@michelangelo:~$ aklog aklog: Couldn't get qwe.cc AFS tickets: aklog: Server not found in Kerberos database while getting AFS tickets jnurmi@michelangelo:~$ aklog -d Authenticating to cell qwe.cc (server qwe.cc). We've deduced that we need to authenticate to realm CC. Getting tickets: afs/qwe.cc@CC Kerberos error code returned by get_cred: -1765328377 aklog: Couldn't get qwe.cc AFS tickets: aklog: Server not found in Kerberos database while getting AFS tickets jnurmi@michelangelo:~$ aklog qwe.cc -k QWE.CC aklog: unable to obtain tokens for cell qwe.cc (status: a pioctl failed). jnurmi@michelangelo:~$ Script done on Sat Mar 20 14:54:43 2004 The last error was from the lack of module & client, this is just a dbserver in reality, and running lin v. 2.6.4, but I _can_ completely work w/ the system remotely, so long as I do the above, I got volumes on it, etc. But it just seems that this shouldnt require such a workaround on the local. (I'm more or less just getting prepped. Some inspired coder will fix/finish/whatever openafs in 2.6 :-D, so I played with it for a while yesterday :-P). Yes I know at this point I'm trading one error for another with no immediate solution, but hey, it's fun :-) James From russ@cs.pitt.edu Sat Mar 20 20:54:28 2004 From: russ@cs.pitt.edu (Russ Howard) Date: Sat, 20 Mar 2004 15:54:28 -0500 Subject: [OpenAFS] Still seeing problems with Drive Letters tab in new OpenAFS Windows build Message-ID: <200403202054.i2KKsBxP031123@gomez.cs.pitt.edu> I just downloaded and installed the test build that was created today and am still seeing problems with the "Drive Letters" tab in afscreds. Here's what I'm seeing: - I click on the padlock tray icon to bring up afscreds and it comes up almost instantaneously. - I left-click on and switch back and forth between the "Tokens" and "Advanced" tabs repeatedly with no problems. - When I click on the "Drive Letters" tab, it takes anywhere between 7-12 seconds for the interface to refresh and the "Drive Letters" interface to come up. If I bring up the Task Manager and watch it during the switching of tabs, I'm seeing the following: After about 5-6 seconds, the status of the AFS Client (afscreds) changes from "Running" to "Not Responding". It stays in the not responding state until the interface refreshes itself. Also, sometimes, during the switch, two listings for the AFS Client will appear in the Task Manager listing, one listed constantly as "Not Responding" and the other that cycles between "Not Responding" and "Running". The duplicate entry will disappear when the AFS Client interface correctly updates itself. - Clicking on another tab to switch from the "Drive Letters" tab also takes 7-12 seconds to switch with the same behavior in the Task Manager noted above. - After access the "Drive Letters" tab, I can no longer right-click on the tray icon to access the context menu items reliably. Sometimes, the context menu will never appear, other times, it will appear after a minute or two at the point where my mouse pointer is currently on the screen. However, I am unable to interact with the menu and the only way to remove it is to kill the afscreds.exe process. - After accessing the "Drive Letters" tab, if I put my mouse pointer over the AFS Client tray icon (I don't even have to click on it), the AFS Client status in the Task Manager starts cycling between the "Running" and "Not Responding" states. The cycle goes like this: approximately 5 seconds in the "Running" state followed by approximately 2 seconds in the "Not Responding" state. I hope these descriptions may be of some help. --- Russ Howard From warlord@MIT.EDU Sat Mar 20 21:00:12 2004 From: warlord@MIT.EDU (Derek Atkins) Date: Sat, 20 Mar 2004 16:00:12 -0500 Subject: [OpenAFS] Kerberos troubles... (addl) In-Reply-To: <1079813868.4737.26.camel@qwe.cc> (J. D. Nurmi's message of "Sat, 20 Mar 2004 15:17:48 -0500") References: <1079718027.18012.37.camel@qwe.cc> <1079720469.18012.48.camel@qwe.cc> <405C9EDF.4FFB260C@anl.gov> <1079813868.4737.26.camel@qwe.cc> Message-ID: "J. D. Nurmi" writes: > jnurmi@michelangelo:~$ aklog -d > Authenticating to cell qwe.cc (server qwe.cc). > We've deduced that we need to authenticate to realm CC. > Getting tickets: afs/qwe.cc@CC This is the problem. It thinks your server is in realm CC. > Kerberos error code returned by get_cred: -1765328377 > aklog: Couldn't get qwe.cc AFS tickets: > aklog: Server not found in Kerberos database while getting AFS tickets > > jnurmi@michelangelo:~$ aklog qwe.cc -k QWE.CC > aklog: unable to obtain tokens for cell qwe.cc (status: a pioctl > failed). > jnurmi@michelangelo:~$ This proves that you have your KDC configured properly for QWE.CC. Try changing the CellServDB and setting the 'hostname' to 'afs1.qwe.cc' instead of 'qwe.cc'. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From dgm+@pitt.edu Sat Mar 20 21:57:57 2004 From: dgm+@pitt.edu (Dave McMurtrie) Date: Sat, 20 Mar 2004 16:57:57 -0500 (EST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 In-Reply-To: References: <0HUU00G1AM14IW@mailbox.slac.stanford.edu> Message-ID: On Sat, 20 Mar 2004, Derrick J Brashear wrote: > Well, I think maybe the key fact we just learned is a fileserver restart > is involved. Are you willing (do you have time) to try that test case if I > give you a fileserver you can knock over? No problem. I found the code I wrote back when I was working on this before. I'll wait to hear from you. Thanks, Dave -- Dave McMurtrie, Systems Programmer University of Pittsburgh Computing Services and Systems Development, Development Services -- UNIX and VMS Services 717P Cathedral of Learning (412)-624-6413 PGP/GPG Key: http://www.pitt.edu/~dgm/gpgkey.asc.txt From jnurmi-openafs-info@qwe.cc Sun Mar 21 00:15:15 2004 From: jnurmi-openafs-info@qwe.cc (J. D. Nurmi) Date: Sat, 20 Mar 2004 19:15:15 -0500 Subject: [OpenAFS] Kerberos troubles... (addl) In-Reply-To: References: <1079718027.18012.37.camel@qwe.cc> <1079720469.18012.48.camel@qwe.cc> <405C9EDF.4FFB260C@anl.gov> <1079813868.4737.26.camel@qwe.cc> Message-ID: <1079828115.4737.28.camel@qwe.cc> And like magic it works. Thanks all :-) On Sat, 2004-03-20 at 16:00, Derek Atkins wrote: > "J. D. Nurmi" writes: > > > jnurmi@michelangelo:~$ aklog -d > > Authenticating to cell qwe.cc (server qwe.cc). > > We've deduced that we need to authenticate to realm CC. > > Getting tickets: afs/qwe.cc@CC > > This is the problem. It thinks your server is in realm CC. > > > Kerberos error code returned by get_cred: -1765328377 > > aklog: Couldn't get qwe.cc AFS tickets: > > aklog: Server not found in Kerberos database while getting AFS tickets > > > > jnurmi@michelangelo:~$ aklog qwe.cc -k QWE.CC > > aklog: unable to obtain tokens for cell qwe.cc (status: a pioctl > > failed). > > jnurmi@michelangelo:~$ > > This proves that you have your KDC configured properly for QWE.CC. > > Try changing the CellServDB and setting the 'hostname' to > 'afs1.qwe.cc' instead of 'qwe.cc'. > > -derek From jaltman@columbia.edu Sun Mar 21 01:15:09 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sat, 20 Mar 2004 20:15:09 -0500 Subject: [OpenAFS] OpenAFS for Windows vs XP SP2 In-Reply-To: <200403202054.i2KKsBxP031123@gomez.cs.pitt.edu> References: <200403202054.i2KKsBxP031123@gomez.cs.pitt.edu> Message-ID: <405CEC9D.8080001@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms080101000101090003050006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It has been brought to my attention that at least one of the cases where the long delay times are taking place are on Windows XP SP2 systems. I am already aware that there may be some compatibility issues between OpenAFS and XP SP2 because of changes in the RPC service. I have not begun to address these issues. Are all of the systems on which people are reporting problem XP SP2? Thanks Jeffrey Altman --------------ms080101000101090003050006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyMTAxMTUwOVowIwYJKoZIhvcNAQkEMRYEFPCqmyKJSBdO oGEvzAQaBb5LsTe/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAe2J/mtcwTfkcZOxX5VKYISoN7uHe 60n6yvwUyNUTJSfn7Eco8UmX+ueP7C320egLBzVy0OMvv369pD3sC4dmIbfxya9Mq28EjLKJ kUrL/7W6LG1nH5UanQ3V6fPLhXkQXhr+6JTZobGKL/NFXydCCMzPZkpLIajRqPf8eCQOn9xP 76FIt20n5j69+ltI7DF2gT38INKx94mamZTVelm4Z6HirneSbnDEaCf0FjuDhd/jeeCkuMKB loNmTSjvaU1gy291SNn1UfbEIoP7zvxez1YLqkKzcwogT0F53M8VAgM8a/UQKm0fKc5ywTo6 HlTU7yKzbBO6QqHqUwCa6NmtXQAAAAAAAA== --------------ms080101000101090003050006-- From tim@umbc.edu Sun Mar 21 05:45:33 2004 From: tim@umbc.edu (Tim C.) Date: Sun, 21 Mar 2004 00:45:33 -0500 (EST) Subject: [OpenAFS] OpenAFS for Windows vs XP SP2 In-Reply-To: <405CEC9D.8080001@columbia.edu> References: <200403202054.i2KKsBxP031123@gomez.cs.pitt.edu> <405CEC9D.8080001@columbia.edu> Message-ID: > It has been brought to my attention that at least one of the cases where > the long delay times are taking place are on Windows XP SP2 systems. > I am already aware that there may be some compatibility issues between > OpenAFS and XP SP2 because of changes in the RPC service. I have > not begun to address these issues. > > Are all of the systems on which people are reporting problem XP SP2? > The behavior I was expiriencing was just like someone else already posted. I am running XP sp1. I haven't tried the latest daily build, but someone said that was showing the same behavior. I will attempt to try that version at some point and let you know if it works for me. Tim ----------------------------------------------------------------------- Tim Craig These are my opinions and not my employers. :) OIT-Systems tim@umbc.edu It's hard to be serious when you're naked. - Garfield ----------------------------------------------------------------------- From jaltman@columbia.edu Sun Mar 21 05:57:17 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sun, 21 Mar 2004 00:57:17 -0500 Subject: [OpenAFS] OpenAFS for Windows vs XP SP2 In-Reply-To: References: <200403202054.i2KKsBxP031123@gomez.cs.pitt.edu> <405CEC9D.8080001@columbia.edu> Message-ID: <405D2EBD.1080008@columbia.edu> This is a multi-part message in MIME format. --------------090804020005080003030908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim C. wrote: > The behavior I was expiriencing was just like someone else already >posted. I am running XP sp1. I haven't tried the latest daily build, >but someone said that was showing the same behavior. I will attempt to >try that version at some point and let you know if it works for me. > >Tim > The behavior which has been described simply means that one or more of the functions which are called during the process of populating the drive list are blocking. I have installed XP SP2 Beta on a machine and been able to demonstrate at least one system in which this problem does not occur. Therefore, we are still at square one when it comes to figuring out which aspect of the system configuration is producing this problem. There must be something common to the systems which are experiencing the problem. Perhaps it is a class of network drivers from a particular vendor; or a particular network configuration (network bridge plus loopback); or a firewall product; or a VPN client; or something else. In the latest build which has been uploaded but not tested by anyone, I have reduced the number of times and under which conditions the network configuration is probed in an attempt to determine the proper Netbios Name. Hopefully this will have a positive impact. If not, I would like to know if the problem is caused by some tricky code which is being used to probe each network interface to determine the display name assigned to the adapter. please try adding the following value to the registry: [HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters] "NoFindLanaByName" (DWORD) = 0x1 Jeffrey Altman --------------090804020005080003030908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tim C. wrote:
  The behavior I was expiriencing was just like someone else already
posted.  I am running XP sp1.  I haven't tried the latest daily build,
but someone said that was showing the same behavior.  I will attempt to
try that version at some point and let you know if it works for me.

Tim
The behavior which has been described simply means
that one or more of the functions which are called
during the process of populating the drive list are
blocking.

I have installed XP SP2 Beta on a machine and been
able to demonstrate at least one system in which
this problem does not occur.  Therefore, we are
still at square one when it comes to figuring out
which aspect of the system configuration is producing
this problem. 

There must be something common to the systems which
are experiencing the problem.  Perhaps it is a class
of network drivers from a particular vendor; or a
particular network configuration (network bridge plus
loopback); or a firewall product; or a VPN client;
or something else.

In the latest build which has been uploaded but
not tested by anyone, I have reduced the number of
times and under which conditions the network configuration
is probed in an attempt to determine the proper
Netbios Name.  Hopefully this will have a positive
impact.

If not, I would like to know if the problem is caused
by some tricky code which is being used to probe each
network interface to determine the display name
assigned to the adapter. 

please try adding the following value to
the registry:

  [HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters]
      "NoFindLanaByName" (DWORD) = 0x1

Jeffrey Altman

--------------090804020005080003030908-- From tim@umbc.edu Sun Mar 21 06:42:09 2004 From: tim@umbc.edu (Tim C.) Date: Sun, 21 Mar 2004 01:42:09 -0500 (EST) Subject: [OpenAFS] OpenAFS for Windows vs XP SP2 In-Reply-To: <405D2EBD.1080008@columbia.edu> References: <200403202054.i2KKsBxP031123@gomez.cs.pitt.edu> <405CEC9D.8080001@columbia.edu> <405D2EBD.1080008@columbia.edu> Message-ID: > The behavior which has been described simply means > that one or more of the functions which are called > during the process of populating the drive list are > blocking. > > I have installed XP SP2 Beta on a machine and been > able to demonstrate at least one system in which > this problem does not occur. Therefore, we are > still at square one when it comes to figuring out > which aspect of the system configuration is producing > this problem. > Oh...I was wondering on the SP2, cause I didn't even see it. It's beta. :) > There must be something common to the systems which > are experiencing the problem. Perhaps it is a class > of network drivers from a particular vendor; or a > particular network configuration (network bridge plus > loopback); or a firewall product; or a VPN client; > or something else. > Okay, I have an orinoco PC card as my main network interface, a 3com 10/100 pc card that is not being used, but is active. And I installed the loopback(before I began testing all of this. I don't have bridging, a firewall, or a vpn client. > In the latest build which has been uploaded but > not tested by anyone, I have reduced the number of > times and under which conditions the network configuration > is probed in an attempt to determine the proper > Netbios Name. Hopefully this will have a positive > impact. > I can't even get this latest version to work at all. I thought it might be how I was installing it, so I've installed it like 3 times. This latest time I went through and removed all files and registry settings associated with the transarc version, and the openafs version. I install it(using all default except setting my cell to "umbc.edu"), reboot, and when I do the icon appears in the tray as normal. I click that and it says "afs service not started, click next to start". When I do it says it can't be started and to check the control panel stuff. So I go to the control panel, launch the afs client configuration, it shows the control panel which I can navigate around, but it has on top a window stating "Please wait; the AFS Client service is stopping". That window doesn't go away until I click cancel on the configuration window. On the configuration window, the Client status says "The AFS Client service is not configured properly". It's like the install didn't work right. I also noticed that there is not a service listed in the administrative services manager. I thought there was one before? > If not, I would like to know if the problem is caused > by some tricky code which is being used to probe each > network interface to determine the display name > assigned to the adapter. > On a similar note, the drive map tab seems to function "normally", even though the service isn't. ;) > please try adding the following value to > the registry: > > [HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters] > "NoFindLanaByName" (DWORD) = 0x1 > I just added this, and I'm rebooting to see if I have any better luck... Same results as above... Tim ----------------------------------------------------------------------- Tim Craig These are my opinions and not my employers. :) OIT-Systems tim@umbc.edu It's hard to be serious when you're naked. - Garfield ----------------------------------------------------------------------- From jaltman@columbia.edu Sun Mar 21 21:28:37 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sun, 21 Mar 2004 16:28:37 -0500 Subject: [OpenAFS] Drive mount tab problem fixed In-Reply-To: <200403212122.i2LLMBxP009923@gomez.cs.pitt.edu> References: <200403212122.i2LLMBxP009923@gomez.cs.pitt.edu> Message-ID: <405E0905.6040701@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms030608030402030300030408 Content-Type: multipart/alternative; boundary="------------000402070903030707090006" This is a multi-part message in MIME format. --------------000402070903030707090006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Russ and Tim: Thank you for confirming that the builds dated today have solved the drive mount tab performance issues. This build also fixes the following problems: * "fs setserverprefs" will leave afsd service deadlocked * "vos listaddrs" will core dump * installer sets the appropriate keys to support Integrated Logon Derrick and I will cut a 1.3.6100 build tonight. Jeffrey Altman --------------000402070903030707090006 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Russ and Tim:

Thank you for confirming that the builds dated today have solved the drive mount tab
performance issues.

This build also fixes the following problems:

 * "fs setserverprefs" will leave afsd service deadlocked

 * "vos listaddrs" will core dump

 * installer sets the appropriate keys to support Integrated Logon

Derrick and I will cut a 1.3.6100 build tonight.

Jeffrey Altman


--------------000402070903030707090006-- --------------ms030608030402030300030408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyMTIxMjgzN1owIwYJKoZIhvcNAQkEMRYEFEtV5wN1dLkg wApLEUtC72eJKMWGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAMhDE+6bDXUQnRfA+Q1PDJHSI/i8r qD5rSzgTp33Ho6zVO8HWk3cROhBpUdJUV/v6fd3WpQkrIH3+irZgS+c8Tx4Xl2Nqk+CdKVEw meWMNzBEkDj6dRVc+l8GCNLjETknlAGjohtzQwpQVTMCEDuLMUtl5w2hkh77SOsJDDmE0mkQ F+msBxfUZ6anShr2j5OJKgqLXALFhTsfTTgodS53eRl/KFYfw4u8UN2hHp/sawYNnAD6E2bR 0J4OggMo9f0kfDpTL6mWED0yVwKozdimfPmnbgPeR3hSLQ9kzHvOBEwfr7TzZRwzBoPd6rHA i7qLzNGqijs6jnPESwQhDWiw+gAAAAAAAA== --------------ms030608030402030300030408-- From Kumar.Padiyath@psi.ch Mon Mar 22 15:33:43 2004 From: Kumar.Padiyath@psi.ch (Padiyath Sreekumaran) Date: Mon, 22 Mar 2004 16:33:43 +0100 Subject: [OpenAFS] AFS + Kerberos 5 Message-ID: Hello, I know this is an Openafs mailing list. I also know that there are many AFS experts in this list. I have a question regarding the kerberos5 + AFS on Tru64 with OS 5.1a. I have installed IBM AFS client SW on our Tru64 machines which works without problem. But we are planning to move to Kerberos 5. I have compiled Kerberos 5 and installed. so that I can execute kinit and aklog to get tokens. But I noticed that now I am getting twice the password prompt when I try to login. I want to combine aklog with the password. I found a Kerberos 5 Tru64 SIA plugin on the net. So I could create a library(libsiakrb5.so) and added to matrix.conf. This helps me not to execute kinit command explicitly. When I login now I get permission errors for my HOME directory since I have not yet executed the aklog command. I have to still execute aklog to have access to my HOME directory. I get the following message when I login: No directory! Logging in with home = "/". Compaq Tru64 UNIX V5.1A (Rev. 1885); Tue Aug 19 10:31:15 MEST 2003 Any idea where I have to make changes inorder to get tokens during login? So I donot get the previous error message. If I execute aklog explicitly after logging I have access to my home directory. My present matrix.conf file: ============================ # sia matrix configuration file (BSD only) siad_setgrent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_endgrent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getgrent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getgrnam=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getgrgid=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_setpwent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_endpwent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getpwent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getpwnam=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getpwuid=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_init=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,li bc.so) siad_chg_finger=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) ( BSD,libc.so) siad_chg_password=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_chg_shell=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (B SD,libc.so) siad_chk_user=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BS matrix.conf # # sia matrix configuration file (BSD only) siad_setgrent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_endgrent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getgrent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getgrnam=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getgrgid=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_setpwent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_endpwent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getpwent=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getpwnam=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_getpwuid=(AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_init=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_chg_finger=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_chg_password=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_chg_shell=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_chk_user=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_ses_init=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_chk_invoker=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_ses_authent=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_ses_suauthent=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_ses_reauthent=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_ses_estab=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_ses_launch=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) siad_ses_release=(KRB5,/usr/shlib/libsiakrb5.so) (AFS,/usr/shlib/libafssiad.so) (BSD,libc.so) Regards, Kumar From rsm4@ieee.org Sun Mar 21 14:53:24 2004 From: rsm4@ieee.org (Rob Murawski) Date: Sun, 21 Mar 2004 09:53:24 -0500 Subject: [OpenAFS] OpenAFS for Windows vs XP SP2 References: <200403202054.i2KKsBxP031123@gomez.cs.pitt.edu> <405CEC9D.8080001@columbia.edu> <405D2EBD.1080008@columbia.edu> Message-ID: <002001c40f54$42a007b0$0600a8c0@robhome.local> Tim, Can you check your PATH setting in Windows? My guess is that it's probably a mess with the multiple OpenAFS installs. Please make sure the AFS directories in the path are listed only once. This will be fixed in the next installer build. -Rob ----- Original Message ----- From: "Tim C." To: "Jeffrey Altman" Cc: Sent: Sunday, March 21, 2004 1:42 AM Subject: Re: [OpenAFS] OpenAFS for Windows vs XP SP2 > > The behavior which has been described simply means > > that one or more of the functions which are called > > during the process of populating the drive list are > > blocking. > > > > I have installed XP SP2 Beta on a machine and been > > able to demonstrate at least one system in which > > this problem does not occur. Therefore, we are > > still at square one when it comes to figuring out > > which aspect of the system configuration is producing > > this problem. > > > Oh...I was wondering on the SP2, cause I didn't even see it. It's > beta. :) > > > There must be something common to the systems which > > are experiencing the problem. Perhaps it is a class > > of network drivers from a particular vendor; or a > > particular network configuration (network bridge plus > > loopback); or a firewall product; or a VPN client; > > or something else. > > > Okay, I have an orinoco PC card as my main network interface, a 3com > 10/100 pc card that is not being used, but is active. And I installed > the loopback(before I began testing all of this. I don't have bridging, > a firewall, or a vpn client. > > > In the latest build which has been uploaded but > > not tested by anyone, I have reduced the number of > > times and under which conditions the network configuration > > is probed in an attempt to determine the proper > > Netbios Name. Hopefully this will have a positive > > impact. > > > I can't even get this latest version to work at all. I thought it > might be how I was installing it, so I've installed it like 3 times. > This latest time I went through and removed all files and registry > settings associated with the transarc version, and the openafs version. > I install it(using all default except setting my cell to "umbc.edu"), > reboot, and when I do the icon appears in the tray as normal. I click > that and it says "afs service not started, click next to start". When I > do it says it can't be started and to check the control panel stuff. So > I go to the control panel, launch the afs client configuration, it shows > the control panel which I can navigate around, but it has on top a > window stating "Please wait; the AFS Client service is stopping". That > window doesn't go away until I click cancel on the configuration window. > On the configuration window, the Client status says "The AFS Client > service is not configured properly". It's like the install didn't work > right. > I also noticed that there is not a service listed in the > administrative services manager. I thought there was one before? > > > If not, I would like to know if the problem is caused > > by some tricky code which is being used to probe each > > network interface to determine the display name > > assigned to the adapter. > > > On a similar note, the drive map tab seems to function "normally", > even though the service isn't. ;) > > > please try adding the following value to > > the registry: > > > > [HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters] > > "NoFindLanaByName" (DWORD) = 0x1 > > > I just added this, and I'm rebooting to see if I have any better > luck... > > Same results as above... > > Tim > > ----------------------------------------------------------------------- > Tim Craig These are my opinions and not my employers. :) > OIT-Systems > tim@umbc.edu It's hard to be serious when you're > naked. - Garfield > ----------------------------------------------------------------------- > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From rees@umich.edu Mon Mar 22 19:11:54 2004 From: rees@umich.edu (Jim Rees) Date: Mon, 22 Mar 2004 14:11:54 -0500 Subject: [OpenAFS] AFS + Kerberos 5 In-Reply-To: Padiyath Sreekumaran, Mon, 22 Mar 2004 16:33:43 +0100 Message-ID: <20040322191156.7CB1020856@citi.umich.edu> You really should consider adding "system:anyuser l" rights to your home directory. Without this many things will break, including for example inbound ssh. From deengert@anl.gov Mon Mar 22 20:15:57 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 22 Mar 2004 14:15:57 -0600 Subject: [OpenAFS] New OpenAFS-1.3.60 for Windows and the SDK Message-ID: <405F497D.BB6B1343@anl.gov> I was hoping to be able to use the SDK from the lastest OpenAFS build with gssklog. src/WINNT/install/NSIS/OpenAFS.nsi appears to only install selected header and lib files. But rx/rxkad.h in the SDK tries to include rxkad_prototypes.h which is not installed with the SDK. Looking at an older 1.3.50 build I have, I see in DEST\include\rx: asn1_err.h, fcrypt.h, rx_protoype.h, rxkad_prototype,h, rs_stat,h and xdr_prototype.h which are not in the latest SDK. There may be other missing files in include and include/afs. Not all of the libs needed are installed either. I have gotten the gssklog down to needing these: $(AFS_LIB_D)\afs\afsauth.lib \ $(AFS_LIB_D)\afs\afspioctl.lib \ $(AFS_LIB_D)\afs\afsutil.lib \ $(AFS_LIB_D)\afs\afscmd.lib \ $(AFS_LIB_D)\afsdes.lib \ $(AFS_LIB_D)\libafsconf.lib If you want I can try and come up with the changes to OpenAFS.nsi to install all the headers and libs. P.S. The gssklog linked against 1.3.50 does run with 1.3.60-20040320. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Renata Maria Dart Mon Mar 22 23:34:15 2004 From: Renata Maria Dart (Renata Maria Dart) Date: Mon, 22 Mar 2004 15:34:15 -0800 (PST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 Message-ID: <0HV000CJX4537K@mailbox.slac.stanford.edu> Hi, here are a few more details regarding our experience with this problem. 1. We only transitioned from Transarc to OpenAFS last year during the summer. Since that time our fileservers have been stable. We did a clean restart of them all once in September (to fix a server key problem), and since then there have been no issues until afs09 started having problems in January. Along with the troubles afs09 has been seeing, users with home directory volumes on it started reporting .gconf lock problems for the first time, after unclean restarts of the fileserver. Derrick mentioned that other AFS admins were reporting .gconf lock problems with no fileserver restart. Could it be that they had the 4a.m. Sunday morning general restart and/or the 5:00a.m. every day automatic restart still set and perhaps didn't even know or remember it? We have ours turned off, both the general and the new binary. Another thought here is that while some users complain very quickly post-crash about their corrupted .gconf directory, others may not use gnome until a week or more after the crash, and if you don't find that out, it may seem like a failure out of the blue. 2. One of our admins who uses gnome, had their home directory volume on afs09. After each round of problems that started with this fileserver crashing in January, and all of which involved an unclean fileserver shutdown and subsequent salvage, he experienced the unremovable .gconf lock. A bos salvage normally fixed the problem for him. But after the last fileserver crash it didn't. I tried moving him to a different server and running a bos salvage there. That still didn't fix the problem. It turned out that he still had an open session from when afs09 had crashed and once he quit out of that, a salvage did fix things. 3. We have a number of fileservers still at 1.2.9. Late last night I upgraded (to get the fix for the solaris fileserver problem that existed in 1.2.9) and cleanly restarted one of them. All of our .gconf lock problems have arisen from unclean fileserver restarts, and so I was curious what kind of fallout there would be from this. So far there have been no reports of gnome problems and one of our admins who's home directory volume was on that fileserver, had an open gnome session at the time and had no problems with either it or with launching new ones. (I realize I am arguing here against my theory in item 1 above that an automatic restart might be the cause of the .gconf locks for the admins who reported no restart. Perhaps it is only an intermittent problem with clean restarts and more reliably reproducible with crashes?) 4. And today, I had a need to restart afs09 and there appears to be no fallout from that restart either. Btw, this restart was needed because one of our admins tried to do a bos salvage and it ran amok again - the salvage ran on for pages so he did a ctl-C and then the fileserver started using 100% of one of the 2 cpus and it could not respond to any vos commands. Can you tell me if there is any information I could gather to help solve this one? Hope this is useful information, -Renata >Date: Sat, 20 Mar 2004 16:57:57 -0500 (EST) >From: Dave McMurtrie >Subject: Re: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 >X-X-Sender: dgm@butthead.cssd.pitt.edu >To: openafs-info@openafs.org >MIME-version: 1.0 >Delivered-to: openafs-info@openafs.org >X-commodore: Commodore_Business_Machines >X-BeenThere: openafs-info@openafs.org >X-Mailman-Version: 2.0.4 >X-PMX-Version: 4.5.0.92886, Antispam-Core: 4.0.4.93542, Antispam-Data: 2004.3.19.94861 >List-Post: >List-Subscribe: , >List-Unsubscribe: , >List-Archive: >List-Help: >List-Id: OpenAFS Info/Discussion >X-Keywords: > >On Sat, 20 Mar 2004, Derrick J Brashear wrote: > >> Well, I think maybe the key fact we just learned is a fileserver restart >> is involved. Are you willing (do you have time) to try that test case if I >> give you a fileserver you can knock over? > >No problem. I found the code I wrote back when I was working on this >before. I'll wait to hear from you. > >Thanks, > >Dave >-- >Dave McMurtrie, Systems Programmer >University of Pittsburgh >Computing Services and Systems Development, >Development Services -- UNIX and VMS Services >717P Cathedral of Learning >(412)-624-6413 > >PGP/GPG Key: http://www.pitt.edu/~dgm/gpgkey.asc.txt >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info Renata Dart | renata@SLAC.Stanford.edu Stanford Linear Accelerator Center | 2575 Sand Hill Road, MS 97 | (650) 926-2848 (office) Stanford, California 94025 | (650) 926-3329 (fax) From shadow@dementia.org Tue Mar 23 00:14:08 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 22 Mar 2004 19:14:08 -0500 (EST) Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 In-Reply-To: <0HV000CJX4537K@mailbox.slac.stanford.edu> References: <0HV000CJX4537K@mailbox.slac.stanford.edu> Message-ID: On Mon, 22 Mar 2004, Renata Maria Dart wrote: > Hi, here are a few more details regarding our experience with this > problem. > > 1. We only transitioned from Transarc to OpenAFS last year > during the summer. Since that time our fileservers have been stable. > We did a clean restart of them all once in September (to fix a server > key problem), and since then there have been no issues until afs09 > started having problems in January. Along with the troubles afs09 > has been seeing, users with home directory volumes on it started > reporting .gconf lock problems for the first time, after unclean > restarts of the fileserver. Derrick mentioned that other AFS > admins were reporting .gconf lock problems with no fileserver > restart. Could it be that they had the 4a.m. Sunday morning general I said, or meant to say, no *unclean* restart. I can't go check the archives, cell-phone-as-modem is slow. > started using 100% of one of the 2 cpus and it could not respond to any > vos commands. Can you tell me if there is any information I could gather > to help solve this one? strace output of the child (not the parent in wait) a core of the child (which you can generate with gcore or gdb's generate-core-file on a running process) From mturk@astro.psu.edu Tue Mar 23 00:31:32 2004 From: mturk@astro.psu.edu (Matthew Turk) Date: Mon, 22 Mar 2004 19:31:32 -0500 (EST) Subject: [OpenAFS] Migration Message-ID: Hi there! At my installation site, we're currently in the process of migrating from an NFS mounted 'storage' system to OpenAFS. The storage system uses about 800gigs of a total of 1.5 terabytes of space, and I was unable to find any information on migration. Is there a preferred migration path? A way of importing existing file systems into OpenAFS, with perhaps mapped usernames (or even not -- resetting the ACLs isn't difficult, as the file structure is quite coherently structured.) Thanks! mjt Penn State Astronomy Dep't From jaltman@columbia.edu Tue Mar 23 03:48:06 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Mon, 22 Mar 2004 22:48:06 -0500 Subject: [OpenAFS] startup dependancies In-Reply-To: <20030918101931.B1387@asu.edu> References: <20030918101931.B1387@asu.edu> Message-ID: <405FB376.3080202@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms020700070609000103010203 Content-Type: multipart/alternative; boundary="------------000709060206050606020702" This is a multi-part message in MIME format. --------------000709060206050606020702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The startup dependencies are now being set in the 1.3.61 installer. They are specified in the NetworkProvider key of the service. DependOnGroup or DependOnService. A service can only be dependent on a service. Since the Explorer.exe process is not a service you cannot depend on it. afscreds.exe -A in 1.3.61 will auto-start the service if it has stopped. If you do not try to use Integrated Logon, then you should not be seeing any OpenAFS messages at logon time. Jeffrey Altman David Bear wrote: >with windows 2k and better, you can list startup dependancies in the >service control manager for a particular service. > >Where can I specify startup depencancies for openafs? I only use >openafs clients. All afs services live on unix boxes. > >I would really like to be able to list something like the windows >'explorer' as a startup dependancy for the afs client to make certain >its the LAST service to start... > > --------------000709060206050606020702 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The startup dependencies are now being set in the 1.3.61
installer.  They are specified in the NetworkProvider key
of the service.    DependOnGroup or DependOnService.
A service can only be dependent on a service.  Since the
Explorer.exe process is not a service you cannot depend
on it.

afscreds.exe -A in 1.3.61 will auto-start the service if it has
stopped.

If you do not try to use Integrated Logon, then you should
not be seeing any OpenAFS messages at logon time.

Jeffrey Altman


David Bear wrote:
with windows 2k and better, you can list startup dependancies in the
service control manager for a particular service.

Where can I specify startup depencancies for openafs?  I only use
openafs clients.  All afs services live on unix boxes.

I would really like to be able to list something like the windows
'explorer' as a startup dependancy for the afs client to make certain
its the LAST service to start...

--------------000709060206050606020702-- --------------ms020700070609000103010203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyMzAzNDgwNlowIwYJKoZIhvcNAQkEMRYEFLPV1fsh/m4z vofdjxMXODzmlZUJMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAGwA2HEZhXLKlJhkK3lDpV5LwD9Wh q1X9u30am7iKAItBYXSaFOYZdW2PgDWH3rVsg/Uz43Uzaesj+E6FdbYjpq9hglX+HpLGoUur UlNJCtsmYF7AfZWAZN5as6z98q8dToXxuojy0422hYQiG4MbWnTQ8rFmT3+N7RWxYUW6RFdP AY0xc5hNcUlzXZ+m9CDRsaMtf/2jzMzP+izMElSdKOkP3oryqE814mBrF/Obngy7kPn0AJGY HF3JAMUvo62iCvhW6TzBZiVPQsveZRoPm1NFa2qz564Li95k+XLQadsbOFNuRzxxWe4+9LD2 nOkPCeSZSzwslZ/WefnA2vvFNQAAAAAAAA== --------------ms020700070609000103010203-- From Todd_Lewis@unc.edu Tue Mar 23 14:00:19 2004 From: Todd_Lewis@unc.edu (Todd M. Lewis) Date: Tue, 23 Mar 2004 09:00:19 -0500 Subject: [OpenAFS] Migration In-Reply-To: References: Message-ID: <406042F3.6050903@email.unc.edu> Matthew Turk wrote: > Hi there! At my installation site, we're currently in the process of > migrating from an NFS mounted 'storage' system to OpenAFS. The storage > system uses about 800gigs of a total of 1.5 terabytes of space, and I was > unable to find any information on migration. > > Is there a preferred migration path? A way of importing existing file > systems into OpenAFS, with perhaps mapped usernames (or even not -- > resetting the ACLs isn't difficult, as the file structure is quite > coherently structured.) > > Thanks! > > mjt > Penn State Astronomy Dep't After a brief look around for strategies to migrate large existing file sets into AFS, I found... nothing. I'm a little surprised nobody has chimed in with some suggestions yet. Some are obvious, and some would apply for setting up a new cell even if you didn't already have gigs of storage ready to move into it. These are just a few thoughts off the top of my head, with the idea of fleshing out an page for the wiki as much as answering your specific questions. Others are encouraged to join in with corrections and additions until we get a critical mass of thoughts for a decent wiki page. Here goes a first shot. * Astronomy dept., eh? You guys have big bits. First thing is to identify large (>2Gb) files in your current store and keep them in the back of your mind as you go through the rest of your migration planning, 'cause you'll need to deal with them somehow. Can they be split into multiple files with some naming convention to tie them together, or can they be compressed and still be made usable? * Think volumes and not just trees. AFS backups are generally done by volumes, so try to pick a volume structure that will keep volume sizes manageable (easy enough to backup, move, replicate). * Unless you have more than your share of geniuses, your existing file store may have developed a few warts over the years. This migration affords an excellent opportunity to organize some of the chaos. OTOH, don't gratuitously change things so much that nobody can find the data they need. * Having said that, avoid the temptation of mounting AFS volumes in more than one place as an aid to reorganizing your file structure. That's usually a sign that the "correct" structure is still eluding you. It can be a useful temporary measure for ongoing reorganizations, but avoid it in general. * With such a large store to move into your AFS cell, you'll need to set up the main volume structure and set the initial ACLs before your start copying data. Study the group and owner permissions in your existing file store and figure out the appropriate ACLs before populating your new tree with files. * If things are going to get complicated, or different enough for your users that confusion abounds, consider creating ".readme" files (for example) in the root of new volumes to explain where this volume's data came from in the old file store, when it was copied, why the ACLs are the way they are, and whatever else might be relevant. Such in situ documentation may help you track how far along your are in your migration. Users aren't used to looking at it though, so if you expect them to use it you'll have some education and some tool building ahead of you. Anybody else care to chime in? -- +--------------------------------------------------------------+ / Todd_Lewis@unc.edu 919-962-5273 http://www.unc.edu/~utoddl / / A good pun is its own reword. / +--------------------------------------------------------------+ From slack@quackmaster.net Tue Mar 23 15:42:40 2004 From: slack@quackmaster.net (Jack Neely) Date: Tue, 23 Mar 2004 10:42:40 -0500 Subject: [OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11 In-Reply-To: <0HV000CJX4537K@mailbox.slac.stanford.edu> References: <0HV000CJX4537K@mailbox.slac.stanford.edu> Message-ID: <20040323154240.GL19520@anduril.pams.ncsu.edu> On Mon, Mar 22, 2004 at 03:34:15PM -0800, Renata Maria Dart wrote: > Hi, here are a few more details regarding our experience with this > problem. > > 1. We only transitioned from Transarc to OpenAFS last year > during the summer. Since that time our fileservers have been stable. > We did a clean restart of them all once in September (to fix a server > key problem), and since then there have been no issues until afs09 > started having problems in January. Along with the troubles afs09 > has been seeing, users with home directory volumes on it started > reporting .gconf lock problems for the first time, after unclean > restarts of the fileserver. Derrick mentioned that other AFS > admins were reporting .gconf lock problems with no fileserver > restart. Could it be that they had the 4a.m. Sunday morning general > restart and/or the 5:00a.m. every day automatic restart still > set and perhaps didn't even know or remember it? We have ours > turned off, both the general and the new binary. Another thought > here is that while some users complain very quickly post-crash > about their corrupted .gconf directory, others may not use gnome > until a week or more after the crash, and if you don't find that > out, it may seem like a failure out of the blue. > I've experianced the .gconf lock issue on Transarc 3.6 servers. I've got some stuff back in the archives about it but I can't for the life of me reproduce the problem on demand. Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From TedAnderson@mindspring.com Tue Mar 23 15:59:48 2004 From: TedAnderson@mindspring.com (Ted Anderson) Date: Tue, 23 Mar 2004 10:59:48 -0500 Subject: [OpenAFS] Migration In-Reply-To: <406042F3.6050903@email.unc.edu> References: <406042F3.6050903@email.unc.edu> Message-ID: <40605EF4.8090509@mindspring.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/23/2004 09:00, Todd M. Lewis wrote: | Matthew Turk wrote: |> Hi there! At my installation site, we're currently in the process of |> migrating from an NFS mounted 'storage' system to OpenAFS. The storage |> system uses about 800gigs of a total of 1.5 terabytes of space, and I was |> unable to find any information on migration. ... |> mjt |> Penn State Astronomy Dep't | | After a brief look around for strategies to migrate large existing file | sets into AFS, I found... nothing. ... These are excellent suggestions, Todd. I suspect that most large AFS cells grew that way, but a question about migration is a sign of AFS's success and having migration suggestions is certainly a good idea. There may be some experience from people migrating to DFS, the concepts related to the data are very similar and would carry over. I read the Chalmers CHIPS[1] report on DCE/DFS[2] at one time, which might be useful to look at. I second Todd's suggestion to think hard about the organization of the namespace at the volume level. You'll be stuck with it for a long time. ~ In many ways AFS is much more forgiving in this area since you aren't bound to specific server and disk configurations. The down side, however, is that there are few disruptive excuses to change the logical layout of your file system, since you aren't forced to copy everything whenever there's a server or disk reorganization. As a hint I would look at the existing structure for symlinks. Thase are often inserted to patch over a needed reorganization that was too painful to deploy at the time. Some of these may indicate opportunities to clean up or highlight areas that change often. I would generally advise that you plan for many small volumes. Data only grows and small volumes will fill out, but initially big volumes may become unwieldy. AFS doesn't provide any fancy tools to repartition volumes, you have to use tar or similar technology (though I guess "up" at least copies ACLs). Certainly any plausible logical boundary should be made a volume boundary, e.g users and projects, sources and binaries, etc. But sometimes it is necessary to break of a logical unit into multiple volumes to keep the sizes down. The main constraint is that volume mount points can't be deleted and recreated by ordinary POSIX tools or applications, so the volume structure needs to be confined to fairly static portions of the namespace. Maybe more experienced admins could discuss the downside of having too many volumes or volumes that are too small? | * With such a large store to move into your AFS cell, you'll need to set | up the main volume structure and set the initial ACLs before your start | copying data. Study the group and owner permissions in your existing | file store and figure out the appropriate ACLs before populating your | new tree with files. Remember that groups in AFS can be created and administered by users. Give some thought to this too, by identify departments, teams, etc. that could reasonably use their own file protection groups and sub-groups. There is a small namespace issue here too, in picking top-level group names that must be created by system:administrator. Ted [1] http://www.chips.chalmers.se/index.en.html [2] http://www.chips.chalmers.se/Chips97/finalreport/FinalReport-Res-DCE.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAYF70jKxQvB9LSQcRAqR4AKCaD811hJfN+FnZNYSYZFzp8CeyDgCg3BVQ Z1m2qIvAyY+CpcsUf2/Riv8= =AVeC -----END PGP SIGNATURE----- From wingc@engin.umich.edu Tue Mar 23 17:08:29 2004 From: wingc@engin.umich.edu (Christopher Allen Wing) Date: Tue, 23 Mar 2004 12:08:29 -0500 (EST) Subject: [OpenAFS] Migration In-Reply-To: Message-ID: As previous posters have written, you'll want to think about separating the data into different AFS volumes based on type. Use read-only/replicated AFS volumes where appropriate. For data that will be written, figure out who the 'owners' and 'groups' should be. You will want to coordinate the user names with the numeric IDs. "Home directories" should be treated according to AFS standards, e.g.: 1. You will probably want all files in the home directories to have the same uid/gid (this may require changing the uid/gid when you copy it over) 2. The root of the home directory should have an ACL like: owner all system:anyuser l 3. All subdirectories should only have: owner all 4. Areas of a 'home directory' that want to be public/shared need to be handled carefully. Some unix permissions can not be expressed in AFS, for instance: anchor% ls -l total 0 -rw------- 1 wingc staff 0 Mar 23 11:46 file1 -rw-r--r-- 1 wingc staff 0 Mar 23 11:46 file2 This will not work in AFS, because 'readability' is a per-directory attribute, not a per-file attribute! (This is something to watch out for, because if you set the ACL so that 'file2' is world-readable, then 'file1' will also be world-readable) We moved a bunch of stuff from local storage into AFS last year, so we might have a script lying around for reference. -Chris Wing wingc@engin.umich.edu On Mon, 22 Mar 2004, Matthew Turk wrote: > Hi there! At my installation site, we're currently in the process of > migrating from an NFS mounted 'storage' system to OpenAFS. The storage > system uses about 800gigs of a total of 1.5 terabytes of space, and I was > unable to find any information on migration. > > Is there a preferred migration path? A way of importing existing file > systems into OpenAFS, with perhaps mapped usernames (or even not -- > resetting the ACLs isn't difficult, as the file structure is quite > coherently structured.) > > Thanks! > > mjt > Penn State Astronomy Dep't From james@burns.net Tue Mar 23 20:20:47 2004 From: james@burns.net (James Burns) Date: Tue, 23 Mar 2004 15:20:47 -0500 (EST) Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <20040323160102.853199CB4@grand.central.org> Message-ID: I tried installing the latest version to see if any of the changes affected the problems I was previously posting about here. Instead upon reboot I was greeted by a Visual C++ runtime buffer overflow and subsequent crash of winlogin.exe. This of course leads to a reboot of the machine. I did not have integrated login enabled, but do have a UareU fingerprint alternate login device. This problem did not exist in 1.3.59 (which simply didn't start as noted previously). When I restarted in safe mode, after logging in there was a dialogue about how the AFS Client didn't start. Uninstalling OpenAFS fixed the crash during normal login. Something seems to be pretty broken. -James From russ@cs.pitt.edu Tue Mar 23 20:54:31 2004 From: russ@cs.pitt.edu (Russ Howard) Date: Tue, 23 Mar 2004 15:54:31 -0500 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: Message-ID: <200403232054.i2NKsYxO009837@gomez.cs.pitt.edu> One of my users has reported getting a buffer overflow message followed by a blue screen pointing to winlogon with 1.3.61 installed. He is running OpenAFS on a laptop with Windows XP SP1. --- Russ Howard -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of James Burns Sent: Tuesday, March 23, 2004 3:21 PM To: openafs-info@openafs.org Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 I tried installing the latest version to see if any of the changes affected the problems I was previously posting about here. Instead upon reboot I was greeted by a Visual C++ runtime buffer overflow and subsequent crash of winlogin.exe. This of course leads to a reboot of the machine. I did not have integrated login enabled, but do have a UareU fingerprint alternate login device. This problem did not exist in 1.3.59 (which simply didn't start as noted previously). When I restarted in safe mode, after logging in there was a dialogue about how the AFS Client didn't start. Uninstalling OpenAFS fixed the crash during normal login. Something seems to be pretty broken. -James _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From Sergio.Gelato@astro.su.se Mon Mar 22 17:43:17 2004 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Mon, 22 Mar 2004 18:43:17 +0100 Subject: [OpenAFS] AFS + Kerberos 5 In-Reply-To: References: Message-ID: <20040322174316.GG2726@hanuman.astro.su.se> * Padiyath Sreekumaran [2004-03-22 16:33:43 +0100]: > I know this is an Openafs mailing list. I also know that there are > many AFS experts in this list. I have a question regarding the > kerberos5 + AFS on Tru64 with OS 5.1a. I have installed IBM > AFS client SW on our Tru64 machines which works without problem. > But we are planning to move to Kerberos 5. I have compiled Kerberos 5 > and installed. > so that I can execute kinit and aklog to get tokens. But I noticed that > now I am getting twice > the password prompt when I try to login. I want to combine aklog > with the password. I found a Kerberos 5 Tru64 SIA plugin on the net. > So I could create a library(libsiakrb5.so) and added to matrix.conf. You may want to take a look at Heimdal's combined Kerberos 5 + AFS SIA module. You'll want to patch it to use krb5_afslog() rather than krb_afslog(), but that's a very easy task. I've done it and can send you the patches. (I should check whether they've been integrated upstream. Maybe they have.) There are some interoperability issues between Heimdal's SIA module and OpenSSH. I had patches against OpenSSH 3.7*p* but with 3.8p1 I found that it was simpler to build OpenSSH --without-osfsia and rely on the built-in KerberosAuthentication and KerberosGetAFSToken support. (I have a patch to make the GetAFSToken support also work with GSSAPI delegated TGTs.) As to what Heimdal version to use, I'd recommend a recent snapshot, possibly on the 0.6 branch (that will become 0.6.1), particularly if you're going to let both MIT and Heimdal libraries manipulate the same credentials caches. An incompatibility was recently fixed that matters on Alpha. > This helps me not to execute kinit command explicitly. When > I login now I get permission errors for my HOME directory since I have > not yet executed the aklog command. I have to still execute > aklog to have access to my HOME directory. I get the following message > when I login: > > No directory! > Logging in with home = "/". > Compaq Tru64 UNIX V5.1A (Rev. 1885); Tue Aug 19 10:31:15 MEST 2003 > > Any idea where I have to make changes inorder to get tokens during > login? So I donot get the previous error message. If I execute aklog > explicitly after logging I have access to my home directory. From jaltman@columbia.edu Tue Mar 23 21:14:58 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Tue, 23 Mar 2004 16:14:58 -0500 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: References: Message-ID: <4060A8D2.5080800@columbia.edu> This is a multi-part message in MIME format. --------------070103030701090804090706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If winlogin.exe is crashing it is because of the afslogon.dll which is being loaded by the registry value HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order ProviderOrder Remove "TransarcAFSDaemon" from the list and the problem should be removed but Integrated Logon will no longer work. I have tested this configuration on Windows 2000 and have seen no problems. I would be interested in knowing if you have the same problem with the DEBUG build http://web.mit.edu/~jaltman/Public/OpenAFS/ If so, there should be a crash log in the registry which would contain a stack trace with symbols that could help identify the source of the problem on your system Jeffrey Altman James Burns wrote: >I tried installing the latest version to see if any of the changes >affected the problems I was previously posting about here. Instead upon >reboot I was greeted by a Visual C++ runtime buffer overflow and >subsequent crash of winlogin.exe. This of course leads to a reboot of the >machine. I did not have integrated login enabled, but do have a UareU >fingerprint alternate login device. This problem did not exist in 1.3.59 >(which simply didn't start as noted previously). When I restarted in safe >mode, after logging in there was a dialogue about how the AFS Client >didn't start. Uninstalling OpenAFS fixed the crash during normal login. >Something seems to be pretty broken. > >-James > >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > --------------070103030701090804090706 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit If winlogin.exe is crashing it is because of the afslogon.dll
which is being loaded by the registry value

    HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
       ProviderOrder

Remove "TransarcAFSDaemon" from the list and the problem
should be removed but Integrated Logon will no longer work.

I have tested this configuration on Windows 2000 and have seen
no problems.  I would be interested in knowing if you have the
same problem with the DEBUG build

    http://web.mit.edu/~jaltman/Public/OpenAFS/

If so, there should be a crash log in the registry which would
contain a stack trace with symbols that could help identify the
source of the problem on your system

Jeffrey Altman



James Burns wrote:
I tried installing the latest version to see if any of the changes 
affected the problems I was previously posting about here. Instead upon 
reboot I was greeted by a Visual C++ runtime buffer overflow and 
subsequent crash of winlogin.exe. This of course leads to a reboot of the 
machine. I did not have integrated login enabled, but do have a UareU 
fingerprint alternate login device. This problem did not exist in 1.3.59 
(which simply didn't start as noted previously). When I restarted in safe 
mode, after logging in there was a dialogue about how the AFS Client 
didn't start. Uninstalling OpenAFS fixed the crash during normal login. 
Something seems to be pretty broken.

-James

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--------------070103030701090804090706-- From deengert@anl.gov Tue Mar 23 21:50:44 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 23 Mar 2004 15:50:44 -0600 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 References: Message-ID: <4060B134.A4D3A587@anl.gov> James Burns wrote: > > I tried installing the latest version to see if any of the changes > affected the problems I was previously posting about here. Instead upon > reboot I was greeted by a Visual C++ runtime buffer overflow and > subsequent crash of winlogin.exe. This of course leads to a reboot of the > machine. I did not have integrated login enabled, but do have a UareU > fingerprint alternate login device. It may be UareU as they replace the GINA with their own! I had one of these installed last week wit version 3.0.0, but uninstalled it to let someone else try it. I will have to see if he has the problem as he installed 1.3.60. (Sundays version) But while I have the UareU installed I did not have any problems with AFS, but I was not using integrated AFS login either. > This problem did not exist in 1.3.59 > (which simply didn't start as noted previously). When I restarted in safe > mode, after logging in there was a dialogue about how the AFS Client > didn't start. Uninstalling OpenAFS fixed the crash during normal login. > Something seems to be pretty broken. > > -James > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman@columbia.edu Tue Mar 23 22:03:40 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Tue, 23 Mar 2004 17:03:40 -0500 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <4060B134.A4D3A587@anl.gov> References: <4060B134.A4D3A587@anl.gov> Message-ID: <4060B43C.6070509@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms040905020707050503070004 Content-Type: multipart/alternative; boundary="------------090509030308080006090409" This is a multi-part message in MIME format. --------------090509030308080006090409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Fact: the afslogon.dll is loaded by winlogin.exe whenever the "TransarcAFSDaemon" is listed within HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder "Order". This is true whether or not Integrated Logon is being used. Fact: the afslogon.dll has not been touched by anyone since the 1.2.8 distribution Fact: the 1.3.50 and higher versions of OpenAFS are compiled using the VS.NET 2003 compiler including the buffer overrun detection option. The 1.2.x versions were compiled with the VC++ 6.0 compiler which did not have buffer overrun detection. Hypothesis: There are buffer overruns taking place within afslogon.dll which have always been there and which are only triggered in some environments. However, previously they were never caught. Now when they are caught an exception is thrown which is causing winlogin.exe to halt. Please install the DEBUG version of the installer from http://web.mit.edu/~jaltman/Public/OpenAFS/ and get me a crash log. Hopefully this will point out the cause of the problem. Jeffrey Altman Douglas E. Engert wrote: > >James Burns wrote: > >>I tried installing the latest version to see if any of the changes >>affected the problems I was previously posting about here. Instead upon >>reboot I was greeted by a Visual C++ runtime buffer overflow and >>subsequent crash of winlogin.exe. This of course leads to a reboot of the >>machine. I did not have integrated login enabled, but do have a UareU >>fingerprint alternate login device. >> > >It may be UareU as they replace the GINA with their own! I had one of these >installed last week wit version 3.0.0, but uninstalled it to let someone else >try it. I will have to see if he has the problem as he installed 1.3.60. >(Sundays version) > >But while I have the UareU installed I did not have any problems with AFS, >but I was not using integrated AFS login either. > > > >>This problem did not exist in 1.3.59 >>(which simply didn't start as noted previously). When I restarted in safe >>mode, after logging in there was a dialogue about how the AFS Client >>didn't start. Uninstalling OpenAFS fixed the crash during normal login. >>Something seems to be pretty broken. >> >>-James >> >>_______________________________________________ >>OpenAFS-info mailing list >>OpenAFS-info@openafs.org >>https://lists.openafs.org/mailman/listinfo/openafs-info >> > --------------090509030308080006090409 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Fact: the afslogon.dll is loaded by winlogin.exe whenever the "TransarcAFSDaemon"
is listed within HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder "Order".
This is true whether or not Integrated Logon is being used.

Fact: the afslogon.dll has not been touched by anyone since the 1.2.8 distribution

Fact: the 1.3.50  and higher versions of OpenAFS are compiled using the VS.NET 2003
compiler including the buffer overrun detection option.  The 1.2.x versions were compiled
with the VC++ 6.0 compiler which did not have buffer overrun detection.

Hypothesis: There are buffer overruns taking place within afslogon.dll which have always
been there and which are only triggered in some environments.  However, previously
they were never caught.  Now when they are caught an exception is thrown which is
causing winlogin.exe to halt. 

Please install the DEBUG version of the installer from http://web.mit.edu/~jaltman/Public/OpenAFS/
and get me a crash log.  Hopefully this will point out the cause of the problem.

Jeffrey Altman



Douglas E. Engert wrote:

James Burns wrote:
I tried installing the latest version to see if any of the changes
affected the problems I was previously posting about here. Instead upon
reboot I was greeted by a Visual C++ runtime buffer overflow and
subsequent crash of winlogin.exe. This of course leads to a reboot of the
machine. I did not have integrated login enabled, but do have a UareU
fingerprint alternate login device. 

It may be UareU as they replace the GINA with their own! I had one of these
installed last week wit version 3.0.0, but uninstalled it to let someone else
try it. I will have to see if he has the problem as he installed 1.3.60.
(Sundays version)

But while I have the UareU installed I did not have any problems with AFS,
but I was not using integrated AFS login either.
 

This problem did not exist in 1.3.59
(which simply didn't start as noted previously). When I restarted in safe
mode, after logging in there was a dialogue about how the AFS Client
didn't start. Uninstalling OpenAFS fixed the crash during normal login.
Something seems to be pretty broken.

-James

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

--------------090509030308080006090409-- --------------ms040905020707050503070004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyMzIyMDM0MFowIwYJKoZIhvcNAQkEMRYEFO/aXF6B+dZX D4N5qanG1+wQsRAkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAa1sdcrrgtWxqcslDQo0GF0geElDr wh9qKmdcVIsQ8AdziM1cMMpavX0/ZiPILT9Uy9iGV2kznn9gegmYg34BGkPLljvni++vStxM xVnMjuf8unc2AOCOSwVz2daLU5Vz5vvDvNkpebpYwYAFETv+ULAKvpMg7AQ4al8nBvM+18U1 uTSlo6KbTfT8i/8rxLMYGknqwo9lwcE8twgW5hBkQy7wng1c4UYep3Oz1wU9qH+0Yg1FcNQS SRXJPht4n+9zjh2wJqVcREhNI/kzObKaSA346h35hr/nQMCuUX0OyWNlFfCWgS+TZdUCFS2O HgnkVQOrvbCI0w4873bG/gWzaAAAAAAAAA== --------------ms040905020707050503070004-- From jaltman@columbia.edu Tue Mar 23 23:59:30 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Tue, 23 Mar 2004 18:59:30 -0500 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <4060B43C.6070509@columbia.edu> References: <4060B134.A4D3A587@anl.gov> <4060B43C.6070509@columbia.edu> Message-ID: <4060CF62.8020301@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms050005000103020807070708 Content-Type: multipart/alternative; boundary="------------040804060201050909090709" This is a multi-part message in MIME format. --------------040804060201050909090709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I just performed a quick audit of the afslogon.c code and fixed several obvious problems including the referencing of uninitialized char[] buffers when generating strings with sprintf() that most definitely could be the cause of the problem. I have uploaded test builds to /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/ http://web.mit.edu/~jaltman/Public/OpenAFS/ OpenAFSforWindows-20040323-01.exe OpenAFSforWindows-DEBUG-20040323-01.exe Please try them out. Jeffrey Altman Jeffrey Altman wrote: > Fact: the afslogon.dll is loaded by winlogin.exe whenever the > "TransarcAFSDaemon" > is listed within > HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder > "Order". > This is true whether or not Integrated Logon is being used. > > Fact: the afslogon.dll has not been touched by anyone since the 1.2.8 > distribution > > Fact: the 1.3.50 and higher versions of OpenAFS are compiled using > the VS.NET 2003 > compiler including the buffer overrun detection option. The 1.2.x > versions were compiled > with the VC++ 6.0 compiler which did not have buffer overrun detection. > > Hypothesis: There are buffer overruns taking place within afslogon.dll > which have always > been there and which are only triggered in some environments. > However, previously > they were never caught. Now when they are caught an exception is > thrown which is > causing winlogin.exe to halt. > > Please install the DEBUG version of the installer from > http://web.mit.edu/~jaltman/Public/OpenAFS/ > and get me a crash log. Hopefully this will point out the cause of > the problem. > > Jeffrey Altman > --------------040804060201050909090709 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I just performed a quick audit of the afslogon.c code and fixed several obvious
problems including the referencing of uninitialized char[] buffers when generating
strings with sprintf() that most definitely could be the cause of the problem.

I have uploaded test builds to

    /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/
    http://web.mit.edu/~jaltman/Public/OpenAFS/

    OpenAFSforWindows-20040323-01.exe
    OpenAFSforWindows-DEBUG-20040323-01.exe

Please try them out.

Jeffrey Altman


Jeffrey Altman wrote:
Fact: the afslogon.dll is loaded by winlogin.exe whenever the "TransarcAFSDaemon"
is listed within HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder "Order".
This is true whether or not Integrated Logon is being used.

Fact: the afslogon.dll has not been touched by anyone since the 1.2.8 distribution

Fact: the 1.3.50  and higher versions of OpenAFS are compiled using the VS.NET 2003
compiler including the buffer overrun detection option.  The 1.2.x versions were compiled
with the VC++ 6.0 compiler which did not have buffer overrun detection.

Hypothesis: There are buffer overruns taking place within afslogon.dll which have always
been there and which are only triggered in some environments.  However, previously
they were never caught.  Now when they are caught an exception is thrown which is
causing winlogin.exe to halt. 

Please install the DEBUG version of the installer from http://web.mit.edu/~jaltman/Public/OpenAFS/
and get me a crash log.  Hopefully this will point out the cause of the problem.

Jeffrey Altman

--------------040804060201050909090709-- --------------ms050005000103020807070708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyMzIzNTkzMFowIwYJKoZIhvcNAQkEMRYEFJs9FLse84nN l6ObNDMCmftXYx24MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAb3b1H9J7RdyAi2Vr+u4duG6mqEno Ol8+ryClrnMKPYieV6P9Am6DgCHiZ9T07gYRjB+lrQDvoXv25t25uZOPym3bG76U6vQpr23c rFP+zYDDwq4Tdrh7Yg6iKfwiThG6vCeA6lfCcfwiBvNITezNMYcRZnNV6hXoXZvovDIE6LKW FxpzfVP7urMy6zIHxKcwaReCLfLB2zfqZI1n0HcwM9L5CtAdFyTDmN776aj1S1B4DzJ+rxUA U87wofGjlfKRj2nSnc2Yc7pj3ZNqCr7coLP+ePsqhG5BFyaZozRAmvggws8sKUSy+IYDQ2eL z2kry9hY111mPa3kIPCs9CZWCwAAAAAAAA== --------------ms050005000103020807070708-- From fbo2@gmx.net Wed Mar 24 09:58:10 2004 From: fbo2@gmx.net (Frank Burkhardt) Date: Wed, 24 Mar 2004 10:58:10 +0100 Subject: [OpenAFS] Kerberos and SSH2 Message-ID: <20040324095810.GA32340@fbo.no-ip.org> Hi, is it possible to use TGT(1)- or/and Token-Forwarding over SSH2? (1) MIT-Kerberos5 Regards, Frank From james@burns.net Wed Mar 24 18:42:25 2004 From: james@burns.net (James Burns) Date: Wed, 24 Mar 2004 13:42:25 -0500 (EST) Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <4060B43C.6070509@columbia.edu> Message-ID: I'll install the debug version when I get home and let you know what happens. Luckily it doesn't happen in safe mode or else I'd have been in a bit of a harder place. -James On Tue, 23 Mar 2004, Jeffrey Altman wrote: > Fact: the afslogon.dll is loaded by winlogin.exe whenever the > "TransarcAFSDaemon" > is listed within > HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder "Order". > This is true whether or not Integrated Logon is being used. > > Fact: the afslogon.dll has not been touched by anyone since the 1.2.8 > distribution > > Fact: the 1.3.50 and higher versions of OpenAFS are compiled using the > VS.NET 2003 > compiler including the buffer overrun detection option. The 1.2.x > versions were compiled > with the VC++ 6.0 compiler which did not have buffer overrun detection. > > Hypothesis: There are buffer overruns taking place within afslogon.dll > which have always > been there and which are only triggered in some environments. However, > previously > they were never caught. Now when they are caught an exception is thrown > which is > causing winlogin.exe to halt. > > Please install the DEBUG version of the installer from > http://web.mit.edu/~jaltman/Public/OpenAFS/ > and get me a crash log. Hopefully this will point out the cause of the > problem. > > Jeffrey Altman > > > > Douglas E. Engert wrote: > > > > >James Burns wrote: > > > >>I tried installing the latest version to see if any of the changes > >>affected the problems I was previously posting about here. Instead upon > >>reboot I was greeted by a Visual C++ runtime buffer overflow and > >>subsequent crash of winlogin.exe. This of course leads to a reboot of the > >>machine. I did not have integrated login enabled, but do have a UareU > >>fingerprint alternate login device. > >> > > > >It may be UareU as they replace the GINA with their own! I had one of these > >installed last week wit version 3.0.0, but uninstalled it to let someone else > >try it. I will have to see if he has the problem as he installed 1.3.60. > >(Sundays version) > > > >But while I have the UareU installed I did not have any problems with AFS, > >but I was not using integrated AFS login either. > > > > > > > >>This problem did not exist in 1.3.59 > >>(which simply didn't start as noted previously). When I restarted in safe > >>mode, after logging in there was a dialogue about how the AFS Client > >>didn't start. Uninstalling OpenAFS fixed the crash during normal login. > >>Something seems to be pretty broken. > >> > >>-James > >> > >>_______________________________________________ > >>OpenAFS-info mailing list > >>OpenAFS-info@openafs.org > >>https://lists.openafs.org/mailman/listinfo/openafs-info > >> > > > From james@burns.net Wed Mar 24 18:44:37 2004 From: james@burns.net (James Burns) Date: Wed, 24 Mar 2004 13:44:37 -0500 (EST) Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <4060CF62.8020301@columbia.edu> Message-ID: Disregard previous, I'll try the test builds, unless you'd like me to try out the debug to see for sure what's broken in the "old" one. -James On Tue, 23 Mar 2004, Jeffrey Altman wrote: > I just performed a quick audit of the afslogon.c code and fixed several > obvious > problems including the referencing of uninitialized char[] buffers when > generating > strings with sprintf() that most definitely could be the cause of the > problem. > > I have uploaded test builds to > > /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/ > http://web.mit.edu/~jaltman/Public/OpenAFS/ > > OpenAFSforWindows-20040323-01.exe > OpenAFSforWindows-DEBUG-20040323-01.exe > > Please try them out. > > Jeffrey Altman > > > Jeffrey Altman wrote: > > > Fact: the afslogon.dll is loaded by winlogin.exe whenever the > > "TransarcAFSDaemon" > > is listed within > > HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder > > "Order". > > This is true whether or not Integrated Logon is being used. > > > > Fact: the afslogon.dll has not been touched by anyone since the 1.2.8 > > distribution > > > > Fact: the 1.3.50 and higher versions of OpenAFS are compiled using > > the VS.NET 2003 > > compiler including the buffer overrun detection option. The 1.2.x > > versions were compiled > > with the VC++ 6.0 compiler which did not have buffer overrun detection. > > > > Hypothesis: There are buffer overruns taking place within afslogon.dll > > which have always > > been there and which are only triggered in some environments. > > However, previously > > they were never caught. Now when they are caught an exception is > > thrown which is > > causing winlogin.exe to halt. > > > > Please install the DEBUG version of the installer from > > http://web.mit.edu/~jaltman/Public/OpenAFS/ > > and get me a crash log. Hopefully this will point out the cause of > > the problem. > > > > Jeffrey Altman > > > From chunsj@embian.com Thu Mar 25 04:36:27 2004 From: chunsj@embian.com (NeXT) Date: Thu, 25 Mar 2004 13:36:27 +0900 Subject: [OpenAFS] [Q] Sudden stop during volume creation.. In-Reply-To: Message-ID: <13b7ea77f7c02b6578704e8ea7a411e1@GNUstep.Home> Yes, right, the log says nothing on that. We are very afraid of the AFS server's stability. On 2004-03-25 02:41:40 +0900 Derrick J Brashear wrote: > Does anything interesting appear in VolserLog or FileLog? I assume > not. > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From james@burns.net Thu Mar 25 05:11:28 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 00:11:28 -0500 (EST) Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <4060CF62.8020301@columbia.edu> Message-ID: I just tried 1.3.62. It no longer crashes, but makes login take about 5 minutes. I haven't tried disabling the dll in the registry yet. When it did finally start up, it says that the server service started, but when trying to configure it I get "Failed to determine the current configuration of this machine. Error: Unknown code d 43 (1067)(0x0000042B)" The client seems to be stuck in the starting state. The afsd_init.log shows: 11:52:11 PM: Create log file 11:52:11 PM: Created log file PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\JDK1.2\BIN;C:\GRAVIS\CORESO~1;C:\PROGRA~1\MCAFEE\MCAFEE~1\MCAFEE~1;F:\cygwin\bin;C:\Program Files\Common Files\Roxio Shared\DLLShared;"C:\Program Files\Symantec\Norton Ghost 2003\";C:\Program Files\Executive Software\Diskeeper\;C:\Program Files\OpenAFS\Client\Program;C:\Program Files\OpenAFS\Common 3/24/2004 11:52:12 PM: osi_InitDebug code 1719 3/24/2004 11:52:12 PM: --- begin dump --- a - dumping scache - cm_currentSCaches=0, cm_maxSCaches=0 a - dumping cm_hashTable - cm_hashTableSize=0 a - Done dumping scache. 3/24/2004 11:52:12 PM: --- end dump --- 3/24/2004 11:52:12 PM: UnhandledException : code : 0x80000003, address: 0x77fa144b --# FV EIP----- RetAddr- FramePtr StackPtr Symbol 0 .V 77fa144b 00401536 007aff78 00000000 DbgBreakPoint 1 .V 00401536 7c2e02f7 007affa4 00000000 2 .V 7c2e02f7 00000000 007affec 00000000 StartServiceCtrlDispatcherW +1739 bytes EXCEPTION_BREAKPOINT - continue execution ... Which seems to be the same error as I was having before. -James On Tue, 23 Mar 2004, Jeffrey Altman wrote: > I just performed a quick audit of the afslogon.c code and fixed several > obvious > problems including the referencing of uninitialized char[] buffers when > generating > strings with sprintf() that most definitely could be the cause of the > problem. > > I have uploaded test builds to > > /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/ > http://web.mit.edu/~jaltman/Public/OpenAFS/ > > OpenAFSforWindows-20040323-01.exe > OpenAFSforWindows-DEBUG-20040323-01.exe > > Please try them out. > > Jeffrey Altman > > > Jeffrey Altman wrote: > > > Fact: the afslogon.dll is loaded by winlogin.exe whenever the > > "TransarcAFSDaemon" > > is listed within > > HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder > > "Order". > > This is true whether or not Integrated Logon is being used. > > > > Fact: the afslogon.dll has not been touched by anyone since the 1.2.8 > > distribution > > > > Fact: the 1.3.50 and higher versions of OpenAFS are compiled using > > the VS.NET 2003 > > compiler including the buffer overrun detection option. The 1.2.x > > versions were compiled > > with the VC++ 6.0 compiler which did not have buffer overrun detection. > > > > Hypothesis: There are buffer overruns taking place within afslogon.dll > > which have always > > been there and which are only triggered in some environments. > > However, previously > > they were never caught. Now when they are caught an exception is > > thrown which is > > causing winlogin.exe to halt. > > > > Please install the DEBUG version of the installer from > > http://web.mit.edu/~jaltman/Public/OpenAFS/ > > and get me a crash log. Hopefully this will point out the cause of > > the problem. > > > > Jeffrey Altman > > > From jaltman@columbia.edu Thu Mar 25 06:05:31 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Wed, 24 Mar 2004 22:05:31 -0800 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: References: Message-ID: <406276AB.10400@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms040700080508040909070500 Content-Type: multipart/alternative; boundary="------------040406080800000606000209" This is a multi-part message in MIME format. --------------040406080800000606000209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit RPC appears to be disabled on your machine. AFS requires the use of RPC. There is no way that AFS could run on it. Error code 1719 is "There are no protocol sequences". This is a windows error indicating that RpcServerUseAllProtseqs() has failed. The reason that afslogon.dll is taking a while to succeed is that it is attempting to start the AFS Client Service which won't start. What policy has been applied to your machine that prevents the loading of RPC Protocols implementations for TCP/IP, NETBIOS, etc. Jeffrey Altman James Burns wrote: >I just tried 1.3.62. It no longer crashes, but makes login take about 5 >minutes. I haven't tried disabling the dll in the registry yet. When it >did finally start up, it says that the server service started, but when >trying to configure it I get "Failed to determine the current >configuration of this machine. Error: Unknown code d 43 >(1067)(0x0000042B)" The client seems to be stuck in the starting state. >The afsd_init.log shows: > >11:52:11 PM: Create log file >11:52:11 PM: Created log file >PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\JDK1.2\BIN;C:\GRAVIS\CORESO~1;C:\PROGRA~1\MCAFEE\MCAFEE~1\MCAFEE~1;F:\cygwin\bin;C:\Program Files\Common Files\Roxio Shared\DLLShared;"C:\Program Files\Symantec\Norton Ghost 2003\";C:\Program Files\Executive Software\Diskeeper\;C:\Program Files\OpenAFS\Client\Program;C:\Program Files\OpenAFS\Common >3/24/2004 11:52:12 PM: osi_InitDebug code 1719 >3/24/2004 11:52:12 PM: --- begin dump --- >a - dumping scache - cm_currentSCaches=0, cm_maxSCaches=0 >a - dumping cm_hashTable - cm_hashTableSize=0 >a - Done dumping scache. >3/24/2004 11:52:12 PM: --- end dump --- >3/24/2004 11:52:12 PM: UnhandledException : code : 0x80000003, address: 0x77fa144b > > >--# FV EIP----- RetAddr- FramePtr StackPtr Symbol > 0 .V 77fa144b 00401536 007aff78 00000000 DbgBreakPoint > 1 .V 00401536 7c2e02f7 007affa4 00000000 > 2 .V 7c2e02f7 00000000 007affec 00000000 StartServiceCtrlDispatcherW +1739 bytes >EXCEPTION_BREAKPOINT - continue execution ... > >Which seems to be the same error as I was having before. > >-James > >>> --------------040406080800000606000209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit RPC appears to be disabled on your machine.
AFS requires the use of RPC.  There is no way that AFS could run on it.

Error code 1719 is "There are no protocol sequences".  This is a windows
error indicating that RpcServerUseAllProtseqs() has failed. 

The reason that afslogon.dll is taking a while to succeed is that it is
attempting to start the AFS Client Service which won't start.

What policy has been applied to your machine that prevents the loading
of RPC Protocols implementations for TCP/IP, NETBIOS, etc.

Jeffrey Altman


James Burns wrote:
I just tried 1.3.62. It no longer crashes, but makes login take about 5 
minutes. I haven't tried disabling the dll in the registry yet. When it 
did finally start up, it says that the server service started, but when 
trying to configure it I get "Failed to determine the current 
configuration of this machine. Error: Unknown code d 43 
(1067)(0x0000042B)" The client seems to be stuck in the starting state. 
The afsd_init.log shows:

11:52:11 PM: Create log file
11:52:11 PM: Created log file
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\JDK1.2\BIN;C:\GRAVIS\CORESO~1;C:\PROGRA~1\MCAFEE\MCAFEE~1\MCAFEE~1;F:\cygwin\bin;C:\Program Files\Common Files\Roxio Shared\DLLShared;"C:\Program Files\Symantec\Norton Ghost 2003\";C:\Program Files\Executive Software\Diskeeper\;C:\Program Files\OpenAFS\Client\Program;C:\Program Files\OpenAFS\Common
3/24/2004 11:52:12 PM: osi_InitDebug code 1719
3/24/2004 11:52:12 PM: --- begin dump ---
a - dumping scache - cm_currentSCaches=0, cm_maxSCaches=0
a - dumping cm_hashTable - cm_hashTableSize=0
a - Done dumping scache.
3/24/2004 11:52:12 PM: --- end   dump ---
3/24/2004 11:52:12 PM: UnhandledException : code : 0x80000003, address: 0x77fa144b


--# FV EIP----- RetAddr- FramePtr StackPtr Symbol
  0 .V 77fa144b 00401536 007aff78 00000000 DbgBreakPoint
  1 .V 00401536 7c2e02f7 007affa4 00000000 
  2 .V 7c2e02f7 00000000 007affec 00000000 StartServiceCtrlDispatcherW +1739 bytes
EXCEPTION_BREAKPOINT - continue execution ...

Which seems to be the same error as I was having before.

-James

--------------040406080800000606000209-- --------------ms040700080508040909070500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNTA2MDUzMVowIwYJKoZIhvcNAQkEMRYEFIAmaqHIpGht JLcJBn2hCHSwqb24MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEATe4KG+N/xiMAa5/HBsyUaHpjHsLc GjrtwG8yYDrcJeCXI/aMDwVb2dmXSUWe75aHGVgd7+hgUggHjH6o+UtkZVmKaXYaReS8Z9ax 3HbzaGsV+AmjYJ/hOl+a8P2j+AbBKvpmSrp7wWSwrB33wtk7YWC7USX9CfXjrJ+3q19vznr8 1lcpoSQW7b83Yy32v1dsKFk6moX26nWzVI+hHPBrbBmxWmMXx2ch3zkoy89C6r4tsGgo67Fl gpvSxoGKTzbwoqRY6nMO0oZLDuWiHMa3Za78MuMnVpOPAtY6YHIQN096SuuR7Oz8fAZymG2s hEwRywgYUPOH5L3+fBonQ/BuUwAAAAAAAA== --------------ms040700080508040909070500-- From jaltman@columbia.edu Thu Mar 25 06:44:10 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Wed, 24 Mar 2004 22:44:10 -0800 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <406276AB.10400@columbia.edu> References: <406276AB.10400@columbia.edu> Message-ID: <40627FBA.60000@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms070306090002080708060601 Content-Type: multipart/alternative; boundary="------------010209040203020501080604" This is a multi-part message in MIME format. --------------010209040203020501080604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Can you specify what keys, values and data are specified in the registry by HKLM\SOFTWARE\Microsoft\Rpc and its children? Jeffrey Altman wrote: > RPC appears to be disabled on your machine. > AFS requires the use of RPC. There is no way that AFS could run on it. > > Error code 1719 is "There are no protocol sequences". This is a windows > error indicating that RpcServerUseAllProtseqs() has failed. > > The reason that afslogon.dll is taking a while to succeed is that it is > attempting to start the AFS Client Service which won't start. > > What policy has been applied to your machine that prevents the loading > of RPC Protocols implementations for TCP/IP, NETBIOS, etc. > > Jeffrey Altman > > --------------010209040203020501080604 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Can you specify what keys, values and data are specified in the registry by

       HKLM\SOFTWARE\Microsoft\Rpc

and its children? 

Jeffrey Altman wrote:
RPC appears to be disabled on your machine.
AFS requires the use of RPC.  There is no way that AFS could run on it.

Error code 1719 is "There are no protocol sequences".  This is a windows
error indicating that RpcServerUseAllProtseqs() has failed. 

The reason that afslogon.dll is taking a while to succeed is that it is
attempting to start the AFS Client Service which won't start.

What policy has been applied to your machine that prevents the loading
of RPC Protocols implementations for TCP/IP, NETBIOS, etc.

Jeffrey Altman



--------------010209040203020501080604-- --------------ms070306090002080708060601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNTA2NDQxMFowIwYJKoZIhvcNAQkEMRYEFEwksO4PX9vT Td0oxSIzhf0wJdQHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAgSLbV+WYovuD1e+uNWEsauD/Nwbz bblZmagT78WD5h4dEFVijUjB0zkT5TQyqQVSLsHLZlXdxBQ7JTQGnjsuJH/z75evHfvJNJHX NN2YhogDyXzlEpDQt4e5yXT4zXFPEz8H+4ON6c4TGiXmWPq+r9J4Cg/LsKo9GjfFDoR1Q+Uv KYUkNj4iT03Glx/OwbjP64/C/7h9ITsGKr42nJDHKmD9ZM2DhwDSwMVAwF8yzNNNGfijP1W+ p/vTasRgPnZpPwdARkwJ8fuX0wgUnEVCeB8uHj4U7txv0GkIw1JCmunXTei35gM1LozhPHl9 ojLXyeizGMLZat2memrRM+PpTAAAAAAAAA== --------------ms070306090002080708060601-- From jaltman@columbia.edu Thu Mar 25 06:47:27 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Wed, 24 Mar 2004 22:47:27 -0800 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <40627FBA.60000@columbia.edu> References: <406276AB.10400@columbia.edu> <40627FBA.60000@columbia.edu> Message-ID: <4062807F.8040505@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms080305080208090209070508 Content-Type: multipart/alternative; boundary="------------020905040406080000030803" This is a multi-part message in MIME format. --------------020905040406080000030803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In particular, you should have this in the registry: ----- cut here --------- REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\*RPC*\ClientProtocols] "ncacn_np"="rpcrt4.dll" "ncacn_ip_tcp"="rpcrt4.dll" "ncadg_ip_udp"="rpcrt4.dll" "ncacn_nb_tcp"="rpcrt4.dll" "ncacn_http"="rpcrt4.dll" ----- cut here --------- Jeffrey Altman wrote: > Can you specify what keys, values and data are specified in the > registry by > > HKLM\SOFTWARE\Microsoft\Rpc > > and its children? > > Jeffrey Altman wrote: > >> RPC appears to be disabled on your machine. >> AFS requires the use of RPC. There is no way that AFS could run on it. >> >> Error code 1719 is "There are no protocol sequences". This is a windows >> error indicating that RpcServerUseAllProtseqs() has failed. >> >> The reason that afslogon.dll is taking a while to succeed is that it is >> attempting to start the AFS Client Service which won't start. >> >> What policy has been applied to your machine that prevents the loading >> of RPC Protocols implementations for TCP/IP, NETBIOS, etc. >> >> Jeffrey Altman >> >> > --------------020905040406080000030803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit In particular, you should have this in the registry:

      ----- cut here ---------
      REGEDIT4

      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RPC\ClientProtocols]
      "ncacn_np"="rpcrt4.dll"
      "ncacn_ip_tcp"="rpcrt4.dll"
      "ncadg_ip_udp"="rpcrt4.dll"
      "ncacn_nb_tcp"="rpcrt4.dll"
      "ncacn_http"="rpcrt4.dll"
      ----- cut here --------- 


Jeffrey Altman wrote:
Can you specify what keys, values and data are specified in the registry by

       HKLM\SOFTWARE\Microsoft\Rpc

and its children? 

Jeffrey Altman wrote:
RPC appears to be disabled on your machine.
AFS requires the use of RPC.  There is no way that AFS could run on it.

Error code 1719 is "There are no protocol sequences".  This is a windows
error indicating that RpcServerUseAllProtseqs() has failed. 

The reason that afslogon.dll is taking a while to succeed is that it is
attempting to start the AFS Client Service which won't start.

What policy has been applied to your machine that prevents the loading
of RPC Protocols implementations for TCP/IP, NETBIOS, etc.

Jeffrey Altman



--------------020905040406080000030803-- --------------ms080305080208090209070508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNTA2NDcyN1owIwYJKoZIhvcNAQkEMRYEFOZtMxEThp9T py90BA6MD2IWC2E0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAlZKHaOzsFrosUt4oQA05HoX0+dcD zCOGLneUcytnE/YYcCCGIzdnuN6A7rSXTp0OS4gtFDPN6z5Lb2pyam9MDI+9ls/poHNxAYnD 0iVK6wxi84NdGkBoAiicFOglJlRm1zXzLrqnfnO7MdUkbBhnrkTYz8qP3m8B2SSutb60qzRK I4RWFyT4sIm51mKRpTAq/2OHChG8mzP/cUvaQUp9sPXVZkJpcte6aRFrZmchqouqVk3OR/Tn qwZswnkcZ8dVuMVq6GyGkettgfm7Pn7Z1HMToHuQtg/tblio0rz9N4xVCXGItndc7NQn4Q8/ I5AEC/Gaf0N6KvyKc/mRwKRSugAAAAAAAA== --------------ms080305080208090209070508-- From shadow@dementia.org Thu Mar 25 07:24:53 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 25 Mar 2004 02:24:53 -0500 (EST) Subject: [OpenAFS] [Q] Sudden stop during volume creation.. In-Reply-To: <13b7ea77f7c02b6578704e8ea7a411e1@GNUstep.Home> References: <13b7ea77f7c02b6578704e8ea7a411e1@GNUstep.Home> Message-ID: On Thu, 25 Mar 2004, NeXT wrote: > Yes, right, the log says nothing on that. We are very afraid of the > AFS server's stability. The flipside is people aren't falling over themselves reporting this problem; it could be your OS, for instance. However... Are you running the volserver out of threads? rxdebug on the volserver port should show you waitprocs, if there are any. > On 2004-03-25 02:41:40 +0900 Derrick J Brashear > wrote: > > > Does anything interesting appear in VolserLog or FileLog? I assume > > not. From chunsj@embian.com Thu Mar 25 08:48:50 2004 From: chunsj@embian.com (NeXT) Date: Thu, 25 Mar 2004 17:48:50 +0900 Subject: [OpenAFS] [Q] Sudden stop during volume creation.. In-Reply-To: Message-ID: <16d1cd35dfbd846c89d63fed3b523821@GNUstep.Home> On 2004-03-25 16:24:53 +0900 Derrick J Brashear wrote: > On Thu, 25 Mar 2004, NeXT wrote: > >> Yes, right, the log says nothing on that. We are very afraid of the >> AFS server's stability. > > The flipside is people aren't falling over themselves reporting this > problem; it could be your OS, for instance. Yes, right, but if it does not work my OS, it is of no use at least for me :-) Strangely enough, some kernel version does not emit this, and even with same kernel, some machine emits these errors, others not. The difference is one receives 15,000 requests per unit time, and other 30,000. > > However... > Are you running the volserver out of threads? > Probably. I'm using Linux version in OpenAFS site. > rxdebug on the volserver port should show you waitprocs, if there are > any. OK, I'll try this. think strace will show more helpful information on the situation :-) > >> On 2004-03-25 02:41:40 +0900 Derrick J Brashear >> wrote: >> >>> Does anything interesting appear in VolserLog or FileLog? I assume >>> not. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From shadow@dementia.org Thu Mar 25 08:56:21 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 25 Mar 2004 03:56:21 -0500 (EST) Subject: [OpenAFS] [Q] Sudden stop during volume creation.. In-Reply-To: <16d1cd35dfbd846c89d63fed3b523821@GNUstep.Home> References: <16d1cd35dfbd846c89d63fed3b523821@GNUstep.Home> Message-ID: On Thu, 25 Mar 2004, NeXT wrote: > > The flipside is people aren't falling over themselves reporting this > > problem; it could be your OS, for instance. > > Yes, right, but if it does not work my OS, it is of no use at least > for me :-) I often find that asking my OS vendor to fix problems with my OS yields better results than asking some other random person to do it. But that's not to say that is your problem, only that you're jumping to conclusions without letting those pesky facts bother you. > Strangely enough, some kernel version does not emit this, and even with > same kernel, some machine emits these errors, others not. The > difference is > one receives 15,000 requests per unit time, and other 30,000. Same hardware? New pthreads library support in kernel versus not? > > Are you running the volserver out of threads? > > > > Probably. I'm using Linux version in OpenAFS site. Not relevant. > > rxdebug on the volserver port should show you waitprocs, if there are > > any. > > OK, I'll try this. think strace will show more helpful information on > the situation :-) No, which is why I suggested a different manner to gather debug info. From james@burns.net Thu Mar 25 11:29:46 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 06:29:46 -0500 (EST) Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <4062807F.8040505@columbia.edu> Message-ID: That worked perfectly. Thank you so much! Any idea about the server error? I'm figuring that it's some old file or registry entry, but I removed all the related ones I could find before installing 1.3.61. -James On Wed, 24 Mar 2004, Jeffrey Altman wrote: > In particular, you should have this in the registry: > > ----- cut here --------- > REGEDIT4 > > [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\*RPC*\ClientProtocols] > "ncacn_np"="rpcrt4.dll" > "ncacn_ip_tcp"="rpcrt4.dll" > "ncadg_ip_udp"="rpcrt4.dll" > "ncacn_nb_tcp"="rpcrt4.dll" > "ncacn_http"="rpcrt4.dll" > ----- cut here --------- > > > > Jeffrey Altman wrote: > > > Can you specify what keys, values and data are specified in the > > registry by > > > > HKLM\SOFTWARE\Microsoft\Rpc > > > > and its children? > > > > Jeffrey Altman wrote: > > > >> RPC appears to be disabled on your machine. > >> AFS requires the use of RPC. There is no way that AFS could run on it. > >> > >> Error code 1719 is "There are no protocol sequences". This is a windows > >> error indicating that RpcServerUseAllProtseqs() has failed. > >> > >> The reason that afslogon.dll is taking a while to succeed is that it is > >> attempting to start the AFS Client Service which won't start. > >> > >> What policy has been applied to your machine that prevents the loading > >> of RPC Protocols implementations for TCP/IP, NETBIOS, etc. > >> > >> Jeffrey Altman > >> > >> > > > From chunsj@embian.com Thu Mar 25 12:04:05 2004 From: chunsj@embian.com (NeXT) Date: Thu, 25 Mar 2004 21:04:05 +0900 Subject: [OpenAFS] [Q] Sudden stop during volume creation.. In-Reply-To: Message-ID: <468d3bac7dea80e0d459ae438a5061e0@GNUstep.Home> On 2004-03-25 17:56:21 +0900 Derrick J Brashear wrote: > Same hardware? New pthreads library support in kernel versus not? > Yes, in same hardware. All kernel supports pthread natively. >> >> Probably. I'm using Linux version in OpenAFS site. > > Not relevant. > I'm sure this version uses posix thread in Linux.(Not sure NPTL or old linux pthread) >> OK, I'll try this. think strace will show more helpful information >> on >> the situation :-) > > No, which is why I suggested a different manner to gather debug info. I'll try. Thanks. From jaltman@columbia.edu Thu Mar 25 16:04:57 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 08:04:57 -0800 Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: References: Message-ID: <40630329.6080706@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms030706010100020908090503 Content-Type: multipart/alternative; boundary="------------060503090401090400080403" This is a multi-part message in MIME format. --------------060503090401090400080403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The failure to have any RPC support on your machine at all is the cause of the AFS Client Service failing to start. Now the big question is "why did your system not have any RPC transport protocols installed"? Jeffrey Altman James Burns wrote: >That worked perfectly. Thank you so much! Any idea about the server error? >I'm figuring that it's some old file or registry entry, but I removed all >the related ones I could find before installing 1.3.61. > >-James > >On Wed, 24 Mar 2004, Jeffrey Altman wrote: > > >>In particular, you should have this in the registry: >> >> ----- cut here --------- >> REGEDIT4 >> >> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\*RPC*\ClientProtocols] >> "ncacn_np"="rpcrt4.dll" >> "ncacn_ip_tcp"="rpcrt4.dll" >> "ncadg_ip_udp"="rpcrt4.dll" >> "ncacn_nb_tcp"="rpcrt4.dll" >> "ncacn_http"="rpcrt4.dll" >> ----- cut here --------- >> >> >> >>Jeffrey Altman wrote: >> >> >>>Can you specify what keys, values and data are specified in the >>>registry by >>> >>> HKLM\SOFTWARE\Microsoft\Rpc >>> >>>and its children? >>> >>>Jeffrey Altman wrote: >>> >>> >>>>RPC appears to be disabled on your machine. >>>>AFS requires the use of RPC. There is no way that AFS could run on it. >>>> >>>>Error code 1719 is "There are no protocol sequences". This is a windows >>>>error indicating that RpcServerUseAllProtseqs() has failed. >>>> >>>>The reason that afslogon.dll is taking a while to succeed is that it is >>>>attempting to start the AFS Client Service which won't start. >>>> >>>>What policy has been applied to your machine that prevents the loading >>>>of RPC Protocols implementations for TCP/IP, NETBIOS, etc. >>>> >>>>Jeffrey Altman >>>> >>>> >>>> --------------060503090401090400080403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The failure to have any RPC support on your machine at all is the cause of the
AFS Client Service failing to start.

Now the big question is "why did your system not have any RPC transport
protocols installed"?

Jeffrey Altman

James Burns wrote:
That worked perfectly. Thank you so much! Any idea about the server error? 
I'm figuring that it's some old file or registry entry, but I removed all 
the related ones I could find before installing 1.3.61.

-James

On Wed, 24 Mar 2004, Jeffrey Altman wrote:

In particular, you should have this in the registry:

      ----- cut here ---------
      REGEDIT4

      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\*RPC*\ClientProtocols]
      "ncacn_np"="rpcrt4.dll"
      "ncacn_ip_tcp"="rpcrt4.dll"
      "ncadg_ip_udp"="rpcrt4.dll"
      "ncacn_nb_tcp"="rpcrt4.dll"
      "ncacn_http"="rpcrt4.dll"
      ----- cut here --------- 



Jeffrey Altman wrote:

Can you specify what keys, values and data are specified in the 
registry by

       HKLM\SOFTWARE\Microsoft\Rpc

and its children? 

Jeffrey Altman wrote:

RPC appears to be disabled on your machine.
AFS requires the use of RPC.  There is no way that AFS could run on it.

Error code 1719 is "There are no protocol sequences".  This is a windows
error indicating that RpcServerUseAllProtseqs() has failed. 

The reason that afslogon.dll is taking a while to succeed is that it is
attempting to start the AFS Client Service which won't start.

What policy has been applied to your machine that prevents the loading
of RPC Protocols implementations for TCP/IP, NETBIOS, etc.

Jeffrey Altman


--------------060503090401090400080403-- --------------ms030706010100020908090503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNTE2MDQ1N1owIwYJKoZIhvcNAQkEMRYEFFmbk8bMtk/J MeFZZbCbnQQgmCRyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEALQzrMw800mLicHDjCGr5xxCNvgoA Efm8ficJCZm6VIvFBXrfVY9vy24WmNL8Mp7YAmEJob4ubdZqUN7HyLANcCBCAKd3vrDnHasL ePBQyPWCA8TeS9xScnrJ44MNMq7nGjEJaTx7oqGBf3W/Fso3qvES6OKTMuMtJeCUcqF0665D Wa4njbCOrCa73FjHP0CiGxglR534C1LFluWQnoDMY/BfXkvxWjI7BnOrnFHhwalzzPnWz+aM ukCvB8P1orIHnC3lAzJ/LbtIcrthUbWzPaNwncnxWO8Ps6DRwTyvgsXcqAtASM3LNkUpUiFM KSd0l2WelHW2PfLrdLnAmqa1OQAAAAAAAA== --------------ms030706010100020908090503-- From shadow@dementia.org Thu Mar 25 16:57:15 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 25 Mar 2004 11:57:15 -0500 (EST) Subject: [OpenAFS] [Q] Sudden stop during volume creation.. In-Reply-To: <468d3bac7dea80e0d459ae438a5061e0@GNUstep.Home> References: <468d3bac7dea80e0d459ae438a5061e0@GNUstep.Home> Message-ID: On Thu, 25 Mar 2004, NeXT wrote: > On 2004-03-25 17:56:21 +0900 Derrick J Brashear > wrote: > > > Same hardware? New pthreads library support in kernel versus not? > > > > Yes, in same hardware. All kernel supports pthread natively. > >> > >> Probably. I'm using Linux version in OpenAFS site. > > > > Not relevant. > > > > I'm sure this version uses posix thread in Linux.(Not sure NPTL or old > linux pthread) The glibc version decides what it is, the interface is the same However, if you're using our binaries, you're using a 1.2.x, and 1.2.x used LWP, not pthreads, in the volserver, so never mind. The rxdebug thing should be useful. From Sergio.Gelato@astro.su.se Wed Mar 24 22:15:22 2004 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Wed, 24 Mar 2004 23:15:22 +0100 Subject: [OpenAFS] Kerberos and SSH2 In-Reply-To: <20040324095810.GA32340@fbo.no-ip.org> References: <20040324095810.GA32340@fbo.no-ip.org> Message-ID: <20040324221521.GC4847@astro.su.se> * Frank Burkhardt [2004-03-24 10:58:10 +0100]: > is it possible to use TGT(1)- or/and Token-Forwarding over SSH2? OpenSSH 3.8p1 implements the gssapi-with-mic mechanism of the latest Internet Draft (rev. -07), with Kerberos 5 as the only currently supported GSS mechanism. This does include credential delegation, i.e. in this case TGT forwarding. I've tested it and it works; am in the process of deploying it. With Heimdal, you can even use the KerberosGetAFSToken to get an AFS token on login. With MIT, one way is to invoke aklog or rquivalent from a child process of sshd. Not yet implemented is GSS key exchange, and the gssapi-keyex combined key exchange and authentication mechanism. Some people are said to be working on it. An advantage of GSS key exchange is that one no longer needs host keys, known_hosts files, etc; the host/* service principals together with the rest of the Kerberos infrastructure provide sufficient server authentication to the client. > > (1) MIT-Kerberos5 > > Regards, > > Frank > > From james@burns.net Thu Mar 25 23:15:24 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 18:15:24 -0500 (EST) Subject: [OpenAFS] Problems with 1.3.61 in Windows 2000 In-Reply-To: <40630329.6080706@columbia.edu> Message-ID: I don't know, but that key didn't exist at all. The OS was a 98 -> 2000 upgrade which still plagues me with weird stuff from time to time I think. -James On Thu, 25 Mar 2004, Jeffrey Altman wrote: > The failure to have any RPC support on your machine at all is the cause > of the > AFS Client Service failing to start. > > Now the big question is "why did your system not have any RPC transport > protocols installed"? > > Jeffrey Altman > > James Burns wrote: > > >That worked perfectly. Thank you so much! Any idea about the server error? > >I'm figuring that it's some old file or registry entry, but I removed all > >the related ones I could find before installing 1.3.61. > > > >-James > > > >On Wed, 24 Mar 2004, Jeffrey Altman wrote: > > > > > >>In particular, you should have this in the registry: > >> > >> ----- cut here --------- > >> REGEDIT4 > >> > >> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\*RPC*\ClientProtocols] > >> "ncacn_np"="rpcrt4.dll" > >> "ncacn_ip_tcp"="rpcrt4.dll" > >> "ncadg_ip_udp"="rpcrt4.dll" > >> "ncacn_nb_tcp"="rpcrt4.dll" > >> "ncacn_http"="rpcrt4.dll" > >> ----- cut here --------- > >> > >> > >> > >>Jeffrey Altman wrote: > >> > >> > >>>Can you specify what keys, values and data are specified in the > >>>registry by > >>> > >>> HKLM\SOFTWARE\Microsoft\Rpc > >>> > >>>and its children? > >>> > >>>Jeffrey Altman wrote: > >>> > >>> > >>>>RPC appears to be disabled on your machine. > >>>>AFS requires the use of RPC. There is no way that AFS could run on it. > >>>> > >>>>Error code 1719 is "There are no protocol sequences". This is a windows > >>>>error indicating that RpcServerUseAllProtseqs() has failed. > >>>> > >>>>The reason that afslogon.dll is taking a while to succeed is that it is > >>>>attempting to start the AFS Client Service which won't start. > >>>> > >>>>What policy has been applied to your machine that prevents the loading > >>>>of RPC Protocols implementations for TCP/IP, NETBIOS, etc. > >>>> > >>>>Jeffrey Altman > >>>> > >>>> > >>>> > From james@burns.net Thu Mar 25 23:22:59 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 18:22:59 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <20040325160503.1AEE29CBB@grand.central.org> Message-ID: I'm seeing a strange behavior with the installer. I'm using my own CellServDB. When I select it and click next I get the options for stuff to turn on and off in the config, but the cell name selection is greyed out. This usually causes a delay when starting up because openafs.org isn't in my CellServDB. I believe that all the 1.3.x have this problem. -James From jaltman@columbia.edu Thu Mar 25 23:36:07 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 15:36:07 -0800 Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: References: Message-ID: <40636CE7.60000@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms040308010301010602020907 Content-Type: multipart/alternative; boundary="------------040708030403040106040606" This is a multi-part message in MIME format. --------------040708030403040106040606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Are you sure the "cell name" field is grey'd out? Or is the "cell name" simply selected? James Burns wrote: >I'm seeing a strange behavior with the installer. I'm using my own >CellServDB. When I select it and click next I get the options for stuff to >turn on and off in the config, but the cell name selection is greyed out. >This usually causes a delay when starting up because openafs.org isn't in >my CellServDB. I believe that all the 1.3.x have this problem. > >-James > >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > --------------040708030403040106040606 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Are you sure the "cell name" field is grey'd out?  Or is the "cell name" simply selected?

James Burns wrote:
I'm seeing a strange behavior with the installer. I'm using my own 
CellServDB. When I select it and click next I get the options for stuff to 
turn on and off in the config, but the cell name selection is greyed out. 
This usually causes a delay when starting up because openafs.org isn't in 
my CellServDB. I believe that all the 1.3.x have this problem.

-James

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--------------040708030403040106040606-- --------------ms040308010301010602020907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNTIzMzYwN1owIwYJKoZIhvcNAQkEMRYEFFTtvHE2E5bA lxUIOml1uMeRFKRBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAh1xlcRTaEMmCzOCdDzW7pSYHpItw pPsrnMbxt653w1SjABS/Dd4GetGxjBoVQehoPWa05/bTtmeBnjqnG8IMFOy85VtsDkqhzbyz WJPt7k/tvxSSty3Q5BAoewSVVgmbSZsBTPNUF0t4szJF3n96vPSsWjsbxR4CVRPQdiMIJICT 68vejDZWPiJt3f85Jzw7ZWJbKttgaWNxq1V+8kJGvcfC0Y+A8nnhr4HiUIWK85tj/NgjIxne pj7U0OfZVIUlcny9q695KtAK8MlAOhFheXwSHDDDzodIAGP28/jxqvEQWYha9zdnjoGwlX6V nEo7wtJvl5jeo2CpEViLf8VkhwAAAAAAAA== --------------ms040308010301010602020907-- From nik@zurich.ibm.com Thu Mar 25 23:51:07 2004 From: nik@zurich.ibm.com (Michael Niksch) Date: Fri, 26 Mar 2004 00:51:07 +0100 Subject: [OpenAFS] Re: OpenAFS 1.3.62 release available In-Reply-To: References: Message-ID: <4063706B.3050003@zurich.ibm.com> This is a multi-part message in MIME format. --------------060806040708050300070906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > For Windows, 1.3.62 represents the currently supported client. We > recommend upgrading from previous releases if you are having problems, > several issues from 1.3.61 have been addressed (including integrated > logon issues, installer problems, and a crash on afsd service > shutdown). Unfortunately, I am still having a couple of problems. 1. Stopping the service still causes a crash of afsd_service.exe. 2. Adding a seconds drive mapping in the Drive Letters tab does not refresh the list. 3. I thought I understood that UNC path names have now changed to the generic \\afs\cellname\... rather than the machine-specific \\%computername%-afs\cellname\... However, I still find only the latter, despite my "NetbiosName" being "AFS". I installed with all default settings, except integrated login and my custom cellname and afsdcell.ini. I am attaching my registry settings for reference. Did I miss anything? Do I have to make the "afs" hostname resolve to my loopback address for \\afs to work? 4. Adding global drive letters seems to have a syntax inconsistent with adding user-specific drives, and I haven't been able to make a global drive actually work. On the other hand, deleting a global drive seems to shift it to the list of user-specific drives, where I can neither disable nor delete it. 5. With the old way of mounting root.afs, it was possible to use not only cell mounts, but also symbolic links in that volume. While I admit that this has always been a hack, many sites have come to rely on shortcuts like /afs/@cell, /afs/ThisCell, /afs/z or /afs/zurich in place of of /afs/zurich.ibm.com. 6. If I create a drive mapping for \afs itself, the contents of that drive seems to be built only dynamically, even though I have not turned on cell lookups via DNS. Many people expect to be able to browse through the list of cells specified in afsdcells.ini. 7. While I would prefer to use generic \\afs\cellname\... UNC names, it has proven convenient to also have a global drive mapping for \afs. Drive mappings provide the only way to CD to an AFS directory. Unfortunately, the AFS context menu is also only available using drive letters, not using UNC paths. On the other hand, mapping each cell to a different drive letter quickly causes a mess and a shortage of drive letters. -- Michael Niksch /Zurich/IBM @ IBMCH IBM Zurich Research Laboratory nik@zurich.ibm.com Saeumerstrasse 4 http://www.zurich.ibm.com/~nik/ CH-8803 Rueschlikon / Switzerland P: +41-1-724-8913 F: +41-1-724-8080 --------------060806040708050300070906 Content-Type: text/plain; name="TransarcAFSDaemon.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="TransarcAFSDaemon.txt" //5XAGkAbgBkAG8AdwBzACAAUgBlAGcAaQBzAHQAcgB5ACAARQBkAGkAdABvAHIAIABWAGUA cgBzAGkAbwBuACAANQAuADAAMAANAAoADQAKAFsASABLAEUAWQBfAEwATwBDAEEATABfAE0A QQBDAEgASQBOAEUAXABTAFkAUwBUAEUATQBcAEMAdQByAHIAZQBuAHQAQwBvAG4AdAByAG8A bABTAGUAdABcAFMAZQByAHYAaQBjAGUAcwBcAFQAcgBhAG4AcwBhAHIAYwBBAEYAUwBEAGEA ZQBtAG8AbgBdAA0ACgAiAFQAeQBwAGUAIgA9AGQAdwBvAHIAZAA6ADAAMAAwADAAMAAwADEA MAANAAoAIgBTAHQAYQByAHQAIgA9AGQAdwBvAHIAZAA6ADAAMAAwADAAMAAwADAAMgANAAoA IgBFAHIAcgBvAHIAQwBvAG4AdAByAG8AbAAiAD0AZAB3AG8AcgBkADoAMAAwADAAMAAwADAA MAAwAA0ACgAiAEkAbQBhAGcAZQBQAGEAdABoACIAPQBoAGUAeAAoADIAKQA6ADQAMwAsADAA MAAsADMAYQAsADAAMAAsADUAYwAsADAAMAAsADUAMAAsADAAMAAsADcAMgAsADAAMAAsADYA ZgAsADAAMAAsADYANwAsADAAMAAsADcAMgAsADAAMAAsADYAMQAsADAAMAAsADYAZAAsADAA MAAsAFwADQAKACAAIAAyADAALAAwADAALAA0ADYALAAwADAALAA2ADkALAAwADAALAA2AGMA LAAwADAALAA2ADUALAAwADAALAA3ADMALAAwADAALAA1AGMALAAwADAALAA0AGYALAAwADAA LAA3ADAALAAwADAALAA2ADUALAAwADAALAA2AGUALAAwADAALAA0ADEALAAwADAALAA0ADYA LABcAA0ACgAgACAAMAAwACwANQAzACwAMAAwACwANQBjACwAMAAwACwANAAzACwAMAAwACwA NgBjACwAMAAwACwANgA5ACwAMAAwACwANgA1ACwAMAAwACwANgBlACwAMAAwACwANwA0ACwA MAAwACwANQBjACwAMAAwACwANQAwACwAMAAwACwANwAyACwAMAAwACwANgBmACwAMAAwACwA XAANAAoAIAAgADYANwAsADAAMAAsADcAMgAsADAAMAAsADYAMQAsADAAMAAsADYAZAAsADAA MAAsADUAYwAsADAAMAAsADYAMQAsADAAMAAsADYANgAsADAAMAAsADcAMwAsADAAMAAsADYA NAAsADAAMAAsADUAZgAsADAAMAAsADcAMwAsADAAMAAsADYANQAsADAAMAAsADcAMgAsAFwA DQAKACAAIAAwADAALAA3ADYALAAwADAALAA2ADkALAAwADAALAA2ADMALAAwADAALAA2ADUA LAAwADAALAAyAGUALAAwADAALAA2ADUALAAwADAALAA3ADgALAAwADAALAA2ADUALAAwADAA LAAwADAALAAwADAADQAKACIARABpAHMAcABsAGEAeQBOAGEAbQBlACIAPQAiAE8AcABlAG4A QQBGAFMAIABDAGwAaQBlAG4AdAAgAFMAZQByAHYAaQBjAGUAIgANAAoAIgBPAGIAagBlAGMA dABOAGEAbQBlACIAPQAiAEwAbwBjAGEAbABTAHkAcwB0AGUAbQAiAA0ACgBAAD0AIgAiAA0A CgAiAEQAZQBwAGUAbgBkAE8AbgBHAHIAbwB1AHAAIgA9AGgAZQB4ACgANwApADoANQAwACwA MAAwACwANABlACwAMAAwACwANQAwACwAMAAwACwANQBmACwAMAAwACwANQA0ACwAMAAwACwA NAA0ACwAMAAwACwANAA5ACwAMAAwACwAMAAwACwAMAAwACwAMAAwACwAMAAwAA0ACgAiAEQA ZQBwAGUAbgBkAE8AbgBTAGUAcgB2AGkAYwBlACIAPQBoAGUAeAAoADcAKQA6ADUANAAsADAA MAAsADYAMwAsADAAMAAsADcAMAAsADAAMAAsADYAOQAsADAAMAAsADcAMAAsADAAMAAsADAA MAAsADAAMAAsADQAZQAsADAAMAAsADQANQAsADAAMAAsADUANAAsADAAMAAsAFwADQAKACAA IAA0ADIALAAwADAALAA0ADkALAAwADAALAA0AGYALAAwADAALAA1ADMALAAwADAALAAwADAA LAAwADAALAA1ADIALAAwADAALAA3ADAALAAwADAALAA2ADMALAAwADAALAA1ADMALAAwADAA LAA3ADMALAAwADAALAAwADAALAAwADAALAAwADAALAAwADAADQAKAA0ACgBbAEgASwBFAFkA XwBMAE8AQwBBAEwAXwBNAEEAQwBIAEkATgBFAFwAUwBZAFMAVABFAE0AXABDAHUAcgByAGUA bgB0AEMAbwBuAHQAcgBvAGwAUwBlAHQAXABTAGUAcgB2AGkAYwBlAHMAXABUAHIAYQBuAHMA YQByAGMAQQBGAFMARABhAGUAbQBvAG4AXABOAGUAdAB3AG8AcgBrAFAAcgBvAHYAaQBkAGUA cgBdAA0ACgAiAFAAcgBvAHYAaQBkAGUAcgBQAGEAdABoACIAPQAiAEMAOgBcAFwAUAByAG8A ZwByAGEAbQAgAEYAaQBsAGUAcwBcAFwATwBwAGUAbgBBAEYAUwBcAFwAQwBsAGkAZQBuAHQA XABcAFAAcgBvAGcAcgBhAG0AXABcAGEAZgBzAGwAbwBnAG8AbgAuAGQAbABsACIADQAKACIA QQB1AHQAaABlAG4AdABQAHIAbwB2AGkAZABlAHIAUABhAHQAaAAiAD0AIgBDADoAXABcAFAA cgBvAGcAcgBhAG0AIABGAGkAbABlAHMAXABcAE8AcABlAG4AQQBGAFMAXABcAEMAbABpAGUA bgB0AFwAXABQAHIAbwBnAHIAYQBtAFwAXABhAGYAcwBsAG8AZwBvAG4ALgBkAGwAbAAiAA0A CgAiAEMAbABhAHMAcwAiAD0AZAB3AG8AcgBkADoAMAAwADAAMAAwADAAMAAyAA0ACgAiAFYA ZQByAGIAbwBzAGUATABvAGcAZwBpAG4AZwAiAD0AZAB3AG8AcgBkADoAMAAwADAAMAAwADAA MABhAA0ACgAiAEwAbwBnAG8AbgBPAHAAdABpAG8AbgBzACIAPQBkAHcAbwByAGQAOgAwADAA MAAwADAAMAAwADEADQAKACIATABvAGcAbwBuAFMAYwByAGkAcAB0ACIAPQAiAEMAOgBcAFwA UAByAG8AZwByAGEAbQAgAEYAaQBsAGUAcwBcAFwATwBwAGUAbgBBAEYAUwBcAFwAQwBsAGkA ZQBuAHQAXABcAFAAcgBvAGcAcgBhAG0AXABcAGEAZgBzAGMAcgBlAGQAcwAuAGUAeABlACAA LQA6ACUAcwAgAC0AeAAgAC0AYQAgAC0AbQAgAC0AbgAgAC0AcQAiAA0ACgAiAE4AYQBtAGUA IgA9ACIATwBwAGUAbgBBAEYAUwBEAGEAZQBtAG8AbgAiAA0ACgANAAoAWwBIAEsARQBZAF8A TABPAEMAQQBMAF8ATQBBAEMASABJAE4ARQBcAFMAWQBTAFQARQBNAFwAQwB1AHIAcgBlAG4A dABDAG8AbgB0AHIAbwBsAFMAZQB0AFwAUwBlAHIAdgBpAGMAZQBzAFwAVAByAGEAbgBzAGEA cgBjAEEARgBTAEQAYQBlAG0AbwBuAFwAUABhAHIAYQBtAGUAdABlAHIAcwBdAA0ACgAiAEMA ZQBsAGwAIgA9ACIAegB1AHIAaQBjAGgALgBpAGIAbQAuAGMAbwBtACIADQAKACIAUwBlAGMA dQByAGkAdAB5AEwAZQB2AGUAbAAiAD0AZAB3AG8AcgBkADoAMAAwADAAMAAwADAAMAAxAA0A CgAiAEYAcgBlAGUAbABhAG4AYwBlAEMAbABpAGUAbgB0ACIAPQBkAHcAbwByAGQAOgAwADAA MAAwADAAMAAwADEADQAKACIAVQBzAGUARABOAFMAIgA9AGQAdwBvAHIAZAA6ADAAMAAwADAA MAAwADAAMAANAAoAIgBOAGUAdABiAGkAbwBzAE4AYQBtAGUAIgA9ACIAQQBGAFMAIgANAAoA IgBNAG8AdQBuAHQAUgBvAG8AdAAiAD0AIgAvAGEAZgBzACIADQAKACIAUgB4AE0AYQB4AE0A VABVACIAPQBkAHcAbwByAGQAOgAwADAAMAAwADAANABlAGMADQAKACIASQBzAEcAYQB0AGUA dwBhAHkAIgA9AGQAdwBvAHIAZAA6ADAAMAAwADAAMAAwADAAMAANAAoAIgBIAGkAZABlAEQA bwB0AEYAaQBsAGUAcwAiAD0AZAB3AG8AcgBkADoAMAAwADAAMAAwADAAMAAxAA0ACgAiAFQA cgB1AG4AYwBhAHQAZQBOAGUAdABiAGkAbwBzACIAPQAiAG8AbgAiAA0ACgAiAE4AbwBGAGkA bgBkAEwAYQBuAGEAQgB5AE4AYQBtAGUAIgA9AGQAdwBvAHIAZAA6ADAAMAAwADAAMAAwADAA MQANAAoADQAKAFsASABLAEUAWQBfAEwATwBDAEEATABfAE0AQQBDAEgASQBOAEUAXABTAFkA UwBUAEUATQBcAEMAdQByAHIAZQBuAHQAQwBvAG4AdAByAG8AbABTAGUAdABcAFMAZQByAHYA aQBjAGUAcwBcAFQAcgBhAG4AcwBhAHIAYwBBAEYAUwBEAGEAZQBtAG8AbgBcAFMAZQBjAHUA cgBpAHQAeQBdAA0ACgAiAFMAZQBjAHUAcgBpAHQAeQAiAD0ALgAuAC4ALgANAAoADQAKAFsA SABLAEUAWQBfAEwATwBDAEEATABfAE0AQQBDAEgASQBOAEUAXABTAFkAUwBUAEUATQBcAEMA dQByAHIAZQBuAHQAQwBvAG4AdAByAG8AbABTAGUAdABcAFMAZQByAHYAaQBjAGUAcwBcAFQA cgBhAG4AcwBhAHIAYwBBAEYAUwBEAGEAZQBtAG8AbgBcAEUAbgB1AG0AXQANAAoAIgAwACIA PQAiAFIAbwBvAHQAXABcAEwARQBHAEEAQwBZAF8AVABSAEEATgBTAEEAUgBDAEEARgBTAEQA QQBFAE0ATwBOAFwAXAAwADAAMAAwACIADQAKACIAQwBvAHUAbgB0ACIAPQBkAHcAbwByAGQA OgAwADAAMAAwADAAMAAwADEADQAKACIATgBlAHgAdABJAG4AcwB0AGEAbgBjAGUAIgA9AGQA dwBvAHIAZAA6ADAAMAAwADAAMAAwADAAMQANAAoADQAKAA== --------------060806040708050300070906-- From jaltman@columbia.edu Fri Mar 26 00:01:06 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 16:01:06 -0800 Subject: [OpenAFS] Re: OpenAFS 1.3.62 release available In-Reply-To: <4063706B.3050003@zurich.ibm.com> References: <4063706B.3050003@zurich.ibm.com> Message-ID: <406372C2.8020606@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms090507010302060004080605 Content-Type: multipart/alternative; boundary="------------050309040809030605070709" This is a multi-part message in MIME format. --------------050309040809030605070709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Niksch wrote: > > For Windows, 1.3.62 represents the currently supported client. We > > recommend upgrading from previous releases if you are having problems, > > several issues from 1.3.61 have been addressed (including integrated > > logon issues, installer problems, and a crash on afsd service > > shutdown). > > Unfortunately, I am still having a couple of problems. > > 1. Stopping the service still causes a crash of afsd_service.exe. yes. this is a known problem. we are working on it (unsuccessfully). The problem does not occur for all users and I cannot re-produce it. The problem goes away if you re-compile with VC 6 instead of VS.NET 2003. However, there are reasons why you don't want to do this. > 2. Adding a seconds drive mapping in the Drive Letters tab does not > refresh the list. Please submit a bug to openafs-bugs@openafs.org > 3. I thought I understood that UNC path names have now changed to the > generic \\afs\cellname\... rather than the machine-specific > \\%computername%-afs\cellname\... However, I still find only the > latter, despite my "NetbiosName" being "AFS". I installed with all > default settings, except integrated login and my custom cellname and > afsdcell.ini. I am attaching my registry settings for reference. Did I > miss anything? Do I have to make the "afs" hostname resolve to my > loopback address for \\afs to work? Yes. You must install the loopback adapter for this to work. If you have the loopback installed and it is not working, please submit a report and include your %WINDIR%\TEMP\afsd_init.log file > 4. Adding global drive letters seems to have a syntax inconsistent > with adding user-specific drives, and I haven't been able to make a > global drive actually work. On the other hand, deleting a global drive > seems to shift it to the list of user-specific drives, where I can > neither disable nor delete it. This problem is fix in today's test builds. It only affects people who are not using the loopback adapter. > 5. With the old way of mounting root.afs, it was possible to use not > only cell mounts, but also symbolic links in that volume. While I > admit that this has always been a hack, many sites have come to rely > on shortcuts like /afs/@cell, /afs/ThisCell, /afs/z or /afs/zurich in > place of of /afs/zurich.ibm.com. > In that case do not use Freelance mode. > 6. If I create a drive mapping for \afs itself, the contents of that > drive seems to be built only dynamically, even though I have not > turned on cell lookups via DNS. Many people expect to be able to > browse through the list of cells specified in afsdcells.ini. You cannot browse the list of cells in Freelance mode except those you have mounts. The client is acting as its own afs root instead of relying on the one from the home cell. > 7. While I would prefer to use generic \\afs\cellname\... UNC names, > it has proven convenient to also have a global drive mapping for \afs. > Drive mappings provide the only way to CD to an AFS directory. > Unfortunately, the AFS context menu is also only available using drive > letters, not using UNC paths. On the other hand, mapping each cell to > a different drive letter quickly causes a mess and a shortage of drive > letters. It is known that the AFS context menu does not work on UNC names. There is already a feature request in the request tracker. Jeffrey Altman --------------050309040809030605070709 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Niksch wrote:
> For Windows, 1.3.62 represents the currently supported client. We
> recommend upgrading from previous releases if you are having problems,
> several issues from 1.3.61 have been addressed (including integrated
> logon issues, installer problems, and a crash on afsd service
> shutdown).

Unfortunately, I am still having a couple of problems.

1. Stopping the service still causes a crash of afsd_service.exe.
yes.  this is a known problem. 
we are working on it (unsuccessfully).  The problem does not occur for all users
and I cannot re-produce it.  The problem goes away if you re-compile with VC 6
instead of VS.NET 2003.  However, there are reasons why you don't want to do this.
2. Adding a seconds drive mapping in the Drive Letters tab does not refresh the list.
Please submit a bug to openafs-bugs@openafs.org

3. I thought I understood that UNC path names have now changed to the generic \\afs\cellname\... rather than the machine-specific \\%computername%-afs\cellname\... However, I still find only the latter, despite my "NetbiosName" being "AFS". I installed with all default settings, except integrated login and my custom cellname and afsdcell.ini. I am attaching my registry settings for reference. Did I miss anything? Do I have to make the "afs" hostname resolve to my loopback address for \\afs to work?
Yes.  You must install the loopback adapter for this to work.

If you have the loopback installed and it is not working, please submit a report and
include your %WINDIR%\TEMP\afsd_init.log file
4. Adding global drive letters seems to have a syntax inconsistent with adding user-specific drives, and I haven't been able to make a global drive actually work. On the other hand, deleting a global drive seems to shift it to the list of user-specific drives, where I can neither disable nor delete it.
This problem is fix in today's test builds.  It only affects people who are not using the loopback adapter.

5. With the old way of mounting root.afs, it was possible to use not only cell mounts, but also symbolic links in that volume. While I admit that this has always been a hack, many sites have come to rely on shortcuts like /afs/@cell, /afs/ThisCell, /afs/z or /afs/zurich in place of of /afs/zurich.ibm.com.

In that case do not use Freelance mode.

6. If I create a drive mapping for \afs itself, the contents of that drive seems to be built only dynamically, even though I have not turned on cell lookups via DNS. Many people expect to be able to browse through the list of cells specified in afsdcells.ini.
You cannot browse the list of cells in Freelance mode except those you have mounts.  The client is
acting as its own afs root instead of relying on the one from the home cell.
7. While I would prefer to use generic \\afs\cellname\... UNC names, it has proven convenient to also have a global drive mapping for \afs. Drive mappings provide the only way to CD to an AFS directory. Unfortunately, the AFS context menu is also only available using drive letters, not using UNC paths. On the other hand, mapping each cell to a different drive letter quickly causes a mess and a shortage of drive letters.
It is known that the AFS context menu does not work on UNC names.  There is already a feature
request in the request tracker.


Jeffrey Altman

--------------050309040809030605070709-- --------------ms090507010302060004080605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNjAwMDEwNlowIwYJKoZIhvcNAQkEMRYEFPD54okWhRgs Juxs7Tr3siJqWWnUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAh3kzrGHdxufg54jR49aZAsJ7ezpf xHhQMvnQzSf4WO8KuEUcxjkkqroWkL+Ns80jxSI1o8roH4BZb4+NErvuHdNbuDr6PzuA+SIX pR7CflF+0epWKgsni0b1lkG/ZsNN3admEkMSqlpn6gt7HT+rNvy1YTKrkoXLkGUR0FcPNs2A M7B9a4+jxdoL8jfD/V2OFpNh9Ol+hRiVyrHXwxUhZGiO5c/OERp6kxgskQJ/dn1QyrKNXR3V vAJ3uND3TfB5OiQbeM5fLLLo3VvJVignuox+iJ624gfedKPYma5Coq8C8TKR4oSmChKNC3Ij 9Y2RTf7r6UrqM57CZWXiDVkiLAAAAAAAAA== --------------ms090507010302060004080605-- From shadow@dementia.org Fri Mar 26 00:00:40 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 25 Mar 2004 19:00:40 -0500 (EST) Subject: [OpenAFS] Re: OpenAFS 1.3.62 release available In-Reply-To: <4063706B.3050003@zurich.ibm.com> References: <4063706B.3050003@zurich.ibm.com> Message-ID: On Fri, 26 Mar 2004, Michael Niksch wrote: > 5. With the old way of mounting root.afs, it was possible to use not > only cell mounts, but also symbolic links in that volume. While I admit > that this has always been a hack, many sites have come to rely on > shortcuts like /afs/@cell, /afs/ThisCell, /afs/z or /afs/zurich in place > of of /afs/zurich.ibm.com. I assume if you disable "freelance" you still can. From james@burns.net Fri Mar 26 00:22:15 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 19:22:15 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <40636CE7.60000@columbia.edu> Message-ID: It's grayed out, both the label and the field. For the reinstall (I just reran the installer) it showed my cell name, but for the original install it show an uneditable openafs.org. (My cell name was uneditable in the reinstall also to be clear) -James On Thu, 25 Mar 2004, Jeffrey Altman wrote: > Are you sure the "cell name" field is grey'd out? Or is the "cell name" > simply selected? > > James Burns wrote: > > >I'm seeing a strange behavior with the installer. I'm using my own > >CellServDB. When I select it and click next I get the options for stuff to > >turn on and off in the config, but the cell name selection is greyed out. > >This usually causes a delay when starting up because openafs.org isn't in > >my CellServDB. I believe that all the 1.3.x have this problem. > > > >-James > > > >_______________________________________________ > >OpenAFS-info mailing list > >OpenAFS-info@openafs.org > >https://lists.openafs.org/mailman/listinfo/openafs-info > > > From nik@zurich.ibm.com Fri Mar 26 00:23:10 2004 From: nik@zurich.ibm.com (Michael Niksch) Date: Fri, 26 Mar 2004 01:23:10 +0100 Subject: [OpenAFS] Re: OpenAFS 1.3.62 release available In-Reply-To: <406372C2.8020606@columbia.edu> References: <4063706B.3050003@zurich.ibm.com> <406372C2.8020606@columbia.edu> Message-ID: <406377EE.6000607@zurich.ibm.com> Thanks a lot for your incredibly fast response! Jeffrey Altman wrote: > Michael Niksch wrote: > >> > For Windows, 1.3.62 represents the currently supported client. We >> > recommend upgrading from previous releases if you are having problems, >> > several issues from 1.3.61 have been addressed (including integrated >> > logon issues, installer problems, and a crash on afsd service >> > shutdown). >> >> Unfortunately, I am still having a couple of problems. >> >> 1. Stopping the service still causes a crash of afsd_service.exe. > > yes. this is a known problem. > we are working on it (unsuccessfully). The problem does not occur for > all users > and I cannot re-produce it. The problem goes away if you re-compile > with VC 6 > instead of VS.NET 2003. However, there are reasons why you don't want > to do this. > >> 2. Adding a seconds drive mapping in the Drive Letters tab does not >> refresh the list. > > Please submit a bug to openafs-bugs@openafs.org I'll do that. > >> 3. I thought I understood that UNC path names have now changed to the >> generic \\afs\cellname\... rather than the machine-specific >> \\%computername%-afs\cellname\... However, I still find only the >> latter, despite my "NetbiosName" being "AFS". I installed with all >> default settings, except integrated login and my custom cellname and >> afsdcell.ini. I am attaching my registry settings for reference. Did I >> miss anything? Do I have to make the "afs" hostname resolve to my >> loopback address for \\afs to work? > > Yes. You must install the loopback adapter for this to work. > > If you have the loopback installed and it is not working, please submit > a report and > include your %WINDIR%\TEMP\afsd_init.log file I think I have the loopback adapter installed. At least I can ping 127.0.0.1. So I think I'll have to submit that report, too. > >> 4. Adding global drive letters seems to have a syntax inconsistent >> with adding user-specific drives, and I haven't been able to make a >> global drive actually work. On the other hand, deleting a global drive >> seems to shift it to the list of user-specific drives, where I can >> neither disable nor delete it. > > This problem is fix in today's test builds. It only affects people who > are not using the loopback adapter. > >> 5. With the old way of mounting root.afs, it was possible to use not >> only cell mounts, but also symbolic links in that volume. While I >> admit that this has always been a hack, many sites have come to rely >> on shortcuts like /afs/@cell, /afs/ThisCell, /afs/z or /afs/zurich in >> place of of /afs/zurich.ibm.com. >> > In that case do not use Freelance mode. Where do I turn that off? In general, where are all the new options documented? I did not select to locate cells via DNS at install time. > >> 6. If I create a drive mapping for \afs itself, the contents of that >> drive seems to be built only dynamically, even though I have not >> turned on cell lookups via DNS. Many people expect to be able to >> browse through the list of cells specified in afsdcells.ini. > > You cannot browse the list of cells in Freelance mode except those you > have mounts. The client is > acting as its own afs root instead of relying on the one from the home cell. > >> 7. While I would prefer to use generic \\afs\cellname\... UNC names, >> it has proven convenient to also have a global drive mapping for \afs. >> Drive mappings provide the only way to CD to an AFS directory. >> Unfortunately, the AFS context menu is also only available using drive >> letters, not using UNC paths. On the other hand, mapping each cell to >> a different drive letter quickly causes a mess and a shortage of drive >> letters. > > It is known that the AFS context menu does not work on UNC names. There > is already a feature > request in the request tracker. > > > Jeffrey Altman > -- Michael Niksch /Zurich/IBM @ IBMCH IBM Zurich Research Laboratory nik@zurich.ibm.com Saeumerstrasse 4 http://www.zurich.ibm.com/~nik/ CH-8803 Rueschlikon / Switzerland P: +41-1-724-8913 F: +41-1-724-8080 From jaltman@columbia.edu Fri Mar 26 00:25:25 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 16:25:25 -0800 Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: References: Message-ID: <40637875.7070406@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms080300010103060307020309 Content-Type: multipart/alternative; boundary="------------080705070809020005030500" This is a multi-part message in MIME format. --------------080705070809020005030500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit That is not what the installer script says no what I experience when I use it. You are selecting the "specify a cellservdb file" option? James Burns wrote: >It's grayed out, both the label and the field. For the reinstall (I just >reran the installer) it showed my cell name, but for the original install >it show an uneditable openafs.org. (My cell name was uneditable in the >reinstall also to be clear) > >-James > --------------080705070809020005030500 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit That is not what the installer script says no what I experience when I use it.
You are selecting the "specify a cellservdb file" option?


James Burns wrote:
It's grayed out, both the label and the field. For the reinstall (I just 
reran the installer) it showed my cell name, but for the original install 
it show an uneditable openafs.org. (My cell name was uneditable in the 
reinstall also to be clear)

-James
--------------080705070809020005030500-- --------------ms080300010103060307020309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNjAwMjUyNVowIwYJKoZIhvcNAQkEMRYEFHG3OIvkmJSc ZVTZlVCH6ReC3hjVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAGuijmFFAvkVY9Yj7ifvfoSIzhQS0 nN4riC5vopj80aQdcVDula/TtxRapUlEB6WesG9a+F+155TgiSsxR7u+PaQHRNkxwX44dltP QpvRfn/yHC43HAeZmqrw9aXIMC5qDO0CYO/V9fEnvp+O2Xr/pnCJ5k0u2/QK9K77Ac1en1LB q2xixdbXIewlUGUrRlMAj66oHDFdIEGZUaWa2wskEDtMr7x44cBw9nO9jN86kbOIspvVmk1f OP0xRp8FsrpWSxdfOBaMeowCgKBTCULYwMaxi4ISVfKYZPCT9qYqmrglU67391b/05Y7Siki aQWP55FshiuldvIK8MRPEJ0z9wAAAAAAAA== --------------ms080300010103060307020309-- From jaltman@columbia.edu Fri Mar 26 00:27:35 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 16:27:35 -0800 Subject: [OpenAFS] Re: OpenAFS 1.3.62 release available In-Reply-To: <406377EE.6000607@zurich.ibm.com> References: <4063706B.3050003@zurich.ibm.com> <406372C2.8020606@columbia.edu> <406377EE.6000607@zurich.ibm.com> Message-ID: <406378F7.4030905@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms020306070606090401080406 Content-Type: multipart/alternative; boundary="------------010306030901010201080701" This is a multi-part message in MIME format. --------------010306030901010201080701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Niksch wrote: > > I think I have the loopback adapter installed. At least I can ping > 127.0.0.1. So I think I'll have to submit that report, too. 127.0.0.1 is not a loopback adapter. It is the built-in "loopback". You need to install the Microsoft Loopback Adapter using the Add Hardware Wizard. >> In that case do not use Freelance mode. > > > Where do I turn that off? In general, where are all the new options > documented? I did not select to locate cells via DNS at install time. You selected the option at install time. The values are configured in the Registry. --------------010306030901010201080701 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Niksch wrote:

I think I have the loopback adapter installed. At least I can ping 127.0.0.1. So I think I'll have to submit that report, too.

127.0.0.1 is not a loopback adapter.  It is the built-in "loopback".
You need to install the Microsoft Loopback Adapter using the Add Hardware Wizard.

In that case do not use Freelance mode.

Where do I turn that off? In general, where are all the new options documented? I did not select to locate cells via DNS at install time.
You selected the option at install time.
The values are configured in the Registry.


--------------010306030901010201080701-- --------------ms020306070606090401080406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNjAwMjczNVowIwYJKoZIhvcNAQkEMRYEFEUP6nFD9EUP L3ZP2T92kWaonb59MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAjj+SK+Ad5kk/OU2FmtXb5p7J6/cU g6ugsZOzGbgk9BktXPtdiBeD2qEJX2Pelrvq2dV9RqHszGVzlnzFv+OEsRY0B91yhZdqVns2 zX15/QL0PqrvcdF0DlS2C+6twJF8X/3fiK+htgpbetBiM7q5jDdsf7oonsJkouYA3/9rAZdU VXQqouQpwSh3AMckk2VLEytcIcrx4U4HN62dGfE4HVbMSeOdiImxzZUbGMJ6ZsJpdypPQhu9 NrGjXGElWhMjRPC3LCifU6nKb7AcuW+nwpexe/ZP6f1gU6ZMU2I5y5yKlb8X5mGv3uH7c74p /sfo/AWAeQKDoK3QGDF1qwJd3wAAAAAAAA== --------------ms020306070606090401080406-- From cclausen@acm.org Fri Mar 26 00:37:06 2004 From: cclausen@acm.org (Christopher D. Clausen) Date: Thu, 25 Mar 2004 18:37:06 -0600 Subject: [OpenAFS] Strange Windows Installer Issue References: Message-ID: <02ee01c412ca$b17bc970$1909000a@ad.uiuc.edu> The exact same things occurs when one attempts to install the windows AFS server using the new installer. I install everything and then have to change the cell of my machine from openafs.org. I used the included CellServDB. If I re-run the installer and don't select the AFS Server I can then input a cell name. < wrote: > It's grayed out, both the label and the field. For the reinstall (I > just reran the installer) it showed my cell name, but for the > original install it show an uneditable openafs.org. (My cell name was > uneditable in the reinstall also to be clear) > > -James > > On Thu, 25 Mar 2004, Jeffrey Altman wrote: > >> Are you sure the "cell name" field is grey'd out? Or is the "cell >> name" simply selected? >> >> James Burns wrote: >> >>> I'm seeing a strange behavior with the installer. I'm using my own >>> CellServDB. When I select it and click next I get the options for >>> stuff to turn on and off in the config, but the cell name selection >>> is greyed out. This usually causes a delay when starting up because >>> openafs.org isn't in my CellServDB. I believe that all the 1.3.x >>> have this problem. From jaltman@columbia.edu Fri Mar 26 00:52:59 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 16:52:59 -0800 Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <02ee01c412ca$b17bc970$1909000a@ad.uiuc.edu> References: <02ee01c412ca$b17bc970$1909000a@ad.uiuc.edu> Message-ID: <40637EEB.9010404@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms090009030708030905080903 Content-Type: multipart/alternative; boundary="------------060705070706050804070606" This is a multi-part message in MIME format. --------------060705070706050804070606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If you are installing the "AFS Server" the cell name is configured when you setup the server. Unless you intend to run your own server, don't install it. If you do not install the server you can specify the name of a remote cell. Jeffrey Altman Christopher D. Clausen wrote: >The exact same things occurs when one attempts to install the windows >AFS server using the new installer. I install everything and then have >to change the cell of my machine from openafs.org. I used the included >CellServDB. If I re-run the installer and don't select the AFS Server I >can then input a cell name. > ><Christopher D. Clausen >ACM@UIUC SysAdmin > >On Thursday, March 25, 2004 6:22p wrote: > >>It's grayed out, both the label and the field. For the reinstall (I >>just reran the installer) it showed my cell name, but for the >>original install it show an uneditable openafs.org. (My cell name was >>uneditable in the reinstall also to be clear) >> >>-James >> >>On Thu, 25 Mar 2004, Jeffrey Altman wrote: >> >> >>>Are you sure the "cell name" field is grey'd out? Or is the "cell >>>name" simply selected? >>> >>>James Burns wrote: >>> >>> >>>>I'm seeing a strange behavior with the installer. I'm using my own >>>>CellServDB. When I select it and click next I get the options for >>>>stuff to turn on and off in the config, but the cell name selection >>>>is greyed out. This usually causes a delay when starting up because >>>>openafs.org isn't in my CellServDB. I believe that all the 1.3.x >>>>have this problem. >>>> > >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > --------------060705070706050804070606 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit If you are installing the "AFS Server" the cell name is configured
when you setup the server.  Unless you intend to run your own
server, don't install it.  If you do not install the server you can
specify the name of a remote cell.

Jeffrey Altman

Christopher D. Clausen wrote:
The exact same things occurs when one attempts to install the windows
AFS server using the new installer.  I install everything and then have
to change the cell of my machine from openafs.org.  I used the included
CellServDB.  If I re-run the installer and don't select the AFS Server I
can then input a cell name.

<<CDC
Christopher D. Clausen
ACM@UIUC SysAdmin

On Thursday, March 25, 2004 6:22p <james@burns.net> wrote:
It's grayed out, both the label and the field. For the reinstall (I
just reran the installer) it showed my cell name, but for the
original install it show an uneditable openafs.org. (My cell name was
uneditable in the reinstall also to be clear)

-James

On Thu, 25 Mar 2004, Jeffrey Altman wrote:

Are you sure the "cell name" field is grey'd out?  Or is the "cell
name" simply selected?

James Burns wrote:

I'm seeing a strange behavior with the installer. I'm using my own
CellServDB. When I select it and click next I get the options for
stuff to turn on and off in the config, but the cell name selection
is greyed out. This usually causes a delay when starting up because
openafs.org isn't in my CellServDB. I believe that all the 1.3.x
have this problem.

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--------------060705070706050804070606-- --------------ms090009030708030905080903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNjAwNTI1OVowIwYJKoZIhvcNAQkEMRYEFDU3Xij26OSU 9Z/Bua+p8YB42RE8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAbOZb8QjKdbyuErBPclpGbTDw4Zir +w89B9kx6VEiRvtyb/tOpE2Nbw3unBXwOtgnhRQqz1BIEuq3dZTsxd3OqzQUHFQnIYWsp7Le Z3tIl5ZV7akgO69y0vIPfldEV7DR5uo1N/d3neKIsPg3JiFKE/SvVj9mjranOGxy8WY2K5jS IsE2GlO8ZeIiBbaUgzOQ1hCQSXOkJzhOYhpvmTEgg5gTaT9p7iq3KZKG2fQqrrRVtftAJenu w0QvzYAEWMJRIyy0v6ZAaaNTLOEIXcr4w1BAhrUIzcPXKiBt2ia00Xtf0sgmn0bLLBuQyz37 RBXR3dAvORup/QTlkFtx6ADhfgAAAAAAAA== --------------ms090009030708030905080903-- From james@burns.net Fri Mar 26 02:26:02 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 21:26:02 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <40637875.7070406@columbia.edu> Message-ID: Yes, from my hard drive. However, even though the only entry in the file is for my cell, it still says the greyed out openafs.org. I don't think that it should do that. -James On Thu, 25 Mar 2004, Jeffrey Altman wrote: > That is not what the installer script says no what I experience when I > use it. > You are selecting the "specify a cellservdb file" option? > > > James Burns wrote: > > >It's grayed out, both the label and the field. For the reinstall (I just > >reran the installer) it showed my cell name, but for the original install > >it show an uneditable openafs.org. (My cell name was uneditable in the > >reinstall also to be clear) > > > >-James > > > From jaltman@columbia.edu Fri Mar 26 02:30:55 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 18:30:55 -0800 Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: References: Message-ID: <406395DF.7030409@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms060809080001080906020203 Content-Type: multipart/alternative; boundary="------------060108080805040907060109" This is a multi-part message in MIME format. --------------060108080805040907060109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It is what is supposed to happen when you tell it to install the AFS Server as well. The client and the server must be in the same cell and the AFS Server cell cannot exist until it is configured. In the meantime, the client must point to a valid cell which we ensure will be the case by using openafs.org or the a previously used cell name. Jeffrey Altman James Burns wrote: >Yes, from my hard drive. However, even though the only entry in the file >is for my cell, it still says the greyed out openafs.org. I don't think >that it should do that. > >-James > >On Thu, 25 Mar 2004, Jeffrey Altman wrote: > > >>That is not what the installer script says no what I experience when I >>use it. >>You are selecting the "specify a cellservdb file" option? >> >> >>James Burns wrote: >> >> >>>It's grayed out, both the label and the field. For the reinstall (I just >>>reran the installer) it showed my cell name, but for the original install >>>it show an uneditable openafs.org. (My cell name was uneditable in the >>>reinstall also to be clear) >>> >>>-James >>> >>> --------------060108080805040907060109 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit It is what is supposed to happen when you tell it to install the
AFS Server as well.  The client and the server must be in the
same cell and the AFS Server cell cannot exist until it is
configured.  In the meantime, the client must point to a
valid cell which we ensure will be the case by using openafs.org
or the a previously used cell name.

Jeffrey Altman


James Burns wrote:
Yes, from my hard drive. However, even though the only entry in the file 
is for my cell, it still says the greyed out openafs.org. I don't think 
that it should do that.

-James

On Thu, 25 Mar 2004, Jeffrey Altman wrote:

That is not what the installer script says no what I experience when I 
use it.
You are selecting the "specify a cellservdb file" option?


James Burns wrote:

It's grayed out, both the label and the field. For the reinstall (I just 
reran the installer) it showed my cell name, but for the original install 
it show an uneditable openafs.org. (My cell name was uneditable in the 
reinstall also to be clear)

-James

--------------060108080805040907060109-- --------------ms060809080001080906020203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNjAyMzA1NVowIwYJKoZIhvcNAQkEMRYEFL5ZH12j/oN6 v9oyrNRGONQ/bVcfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAs7PXhN8qbtDsOS8wEYbd8suHjSBv WWDOZ8S1s7OH4NLdGDicyzSwjcy8wKdt0tKPzHua4Va9sMx3PLVZdyW6DwuwAHaar30SggvG 8RfQDPwudzsgWgsrAXCNETdGjqtHDp7E+xvuQuPAOXRRjXjRWZL1Wcydz7GQFUaMTA4pd9cM pEj9esCE2nqRl5N39XkS+cDV0y2LzQrbpPZeoebDF5Gs/eyBmfslvVwd66ortE97wt3rwG/3 IM3XEFtEY/5z4Ot5BFEQC2VbpovnoSMFxnbGDyHmaSvSDUaNJ9nnwqwA9L8MD5oMUZ5E3smz d74nX7mEfPXrpp0nhS9wcd+1xAAAAAAAAA== --------------ms060809080001080906020203-- From james@burns.net Fri Mar 26 02:30:17 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 21:30:17 -0500 (EST) Subject: [OpenAFS] Re: OpenAFS-info digest, Vol 1 #1684 - 7 msgs In-Reply-To: <20040326005304.22BB79D09@grand.central.org> Message-ID: From james@burns.net Fri Mar 26 02:32:51 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 21:32:51 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <40637875.7070406@columbia.edu> Message-ID: I was also installing the server, so that is why it was greyed out apparently. I am still, however, unable to configure the server because of the error that I mentioned before, "Failed to determine current configuration of this machine. Error: Unknown code d 43 (1067)(0x0000042B)" -James On Thu, 25 Mar 2004, Jeffrey Altman wrote: > That is not what the installer script says no what I experience when I > use it. > You are selecting the "specify a cellservdb file" option? > > > James Burns wrote: > > >It's grayed out, both the label and the field. For the reinstall (I just > >reran the installer) it showed my cell name, but for the original install > >it show an uneditable openafs.org. (My cell name was uneditable in the > >reinstall also to be clear) > > > >-James > > > From james@burns.net Fri Mar 26 02:38:06 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 21:38:06 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <406395DF.7030409@columbia.edu> Message-ID: So any ideas on why I'm not able to configure the server still? It's not the first server in the cell, there are two others already. -James On Thu, 25 Mar 2004, Jeffrey Altman wrote: > It is what is supposed to happen when you tell it to install the > AFS Server as well. The client and the server must be in the > same cell and the AFS Server cell cannot exist until it is > configured. In the meantime, the client must point to a > valid cell which we ensure will be the case by using openafs.org > or the a previously used cell name. > > Jeffrey Altman > > > James Burns wrote: > > >Yes, from my hard drive. However, even though the only entry in the file > >is for my cell, it still says the greyed out openafs.org. I don't think > >that it should do that. > > > >-James > > > >On Thu, 25 Mar 2004, Jeffrey Altman wrote: > > > > > >>That is not what the installer script says no what I experience when I > >>use it. > >>You are selecting the "specify a cellservdb file" option? > >> > >> > >>James Burns wrote: > >> > >> > >>>It's grayed out, both the label and the field. For the reinstall (I just > >>>reran the installer) it showed my cell name, but for the original install > >>>it show an uneditable openafs.org. (My cell name was uneditable in the > >>>reinstall also to be clear) > >>> > >>>-James > >>> > >>> > From jaltman@columbia.edu Fri Mar 26 02:46:03 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 18:46:03 -0800 Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: References: Message-ID: <4063996B.5040600@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms000902020008090406010504 Content-Type: multipart/alternative; boundary="------------010609020008020605060500" This is a multi-part message in MIME format. --------------010609020008020605060500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit James Burns wrote: >I was also installing the server, so that is why it was greyed out >apparently. I am still, however, unable to configure the server because of >the error that I mentioned before, "Failed to determine current >configuration of this machine. Error: Unknown code d 43 >(1067)(0x0000042B)" > >-James > The server does not work. No surprise there. It hasn't worked since IBM Open Sourced the code --------------010609020008020605060500 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit James Burns wrote:
I was also installing the server, so that is why it was greyed out 
apparently. I am still, however, unable to configure the server because of 
the error that I mentioned before, "Failed to determine current 
configuration of this machine. Error: Unknown code d 43 
(1067)(0x0000042B)"

-James
The server does not work.  No surprise there.
It hasn't worked since IBM Open Sourced the code


--------------010609020008020605060500-- --------------ms000902020008090406010504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNjAyNDYwM1owIwYJKoZIhvcNAQkEMRYEFFScRb7Z+SWK f4YM5YjyRiDQ5DF/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEALvEhKnOJ+ZR2sjP5x5nAGaD4TD6k uGfH9bahnQvn95PDdRsm8HehmBxDVBndJlryi5MR0MkYGXuWV9/Xtnz8VnUYhz6xQCNc6XZ3 308ZgJH6QhxY78BNY1nGX1xOHIJLT/uDaTm+ffb6DLYZF0IYjBoQNs9kiTEIkaLA0GXlDTmJ oB5ZD3Yhj/rV3NDNo08aT5ji4UFXUQ4BnFZbgEJhiaB7cvyLr9x4EsmEDAp+sxMDP1HhA6qI 2gPLg3t+vUUL93/oqrycK4E8auNdOJSBI/sNyhh2uap/SEeZkAkJYEdDVV2EDfdJ2Zyxk/LC Ew//UDXMBiXROrN3TVru6JIffQAAAAAAAA== --------------ms000902020008090406010504-- From james@burns.net Fri Mar 26 02:49:38 2004 From: james@burns.net (James Burns) Date: Thu, 25 Mar 2004 21:49:38 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <4063996B.5040600@columbia.edu> Message-ID: Ah, I didn't know it didn't work. That clarifies the issue... Oh well. -James On Thu, 25 Mar 2004, Jeffrey Altman wrote: > James Burns wrote: > > >I was also installing the server, so that is why it was greyed out > >apparently. I am still, however, unable to configure the server because of > >the error that I mentioned before, "Failed to determine current > >configuration of this machine. Error: Unknown code d 43 > >(1067)(0x0000042B)" > > > >-James > > > The server does not work. No surprise there. > It hasn't worked since IBM Open Sourced the code > > > From rra@stanford.edu Fri Mar 26 03:07:30 2004 From: rra@stanford.edu (Russ Allbery) Date: Thu, 25 Mar 2004 19:07:30 -0800 Subject: [OpenAFS] Collection of AFS management tools Message-ID: <87d670z4p9.fsf@windlord.stanford.edu> I just presented these at the AFS Best Practices Workshop and wanted to mention them to other readers of the mailing list as well. I've finally found the time to clean up and document many of the AFS management scripts that we use internally at Stanford and have put a fairly large selection of them up on my personal software pages (in the absence of a good Stanford distribution point for such things at the moment). All of these are open source / free software. Feel free to grab them, modify them for your needs, whatever. I welcome patches and am happy to maintain generally useful additions. See the AFS section at: kstart/k5start and runauth may also be of interest in the Kerberos section. -- Russ Allbery (rra@stanford.edu) From bdavids1@gmu.edu Fri Mar 26 06:58:06 2004 From: bdavids1@gmu.edu (Brian Davidson) Date: Thu, 25 Mar 2004 22:58:06 -0800 Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <4063996B.5040600@columbia.edu> References: <4063996B.5040600@columbia.edu> Message-ID: On Mar 25, 2004, at 6:46 PM, Jeffrey Altman wrote: > The server does not work.=A0 No surprise there. > It hasn't worked since IBM Open Sourced the code > Has there been any thought given to removing the server pieces from the=20= installer? Even if it worked, it seems to me that 2 installers, one=20 for the client and one for the server, would be better. 99% of the=20 installs are going to be clients, not servers, so a client only=20 installer would be easiest for most users. I've noticed a tendency for "Power Users" to decide that the options=20 which weren't checked by default must be the things that turn on the=20 cool features, so they just check everything (the 'default' power user=20= config if you will). If I'm an AFS cell admin, I really don't mind grabbing a separate=20 installer for the server. Granted, it's extra work when building the installer(s). I'm not=20 familiar yet with the install building tool you're using, so I don't=20 know how much extra work it would entail. I'll be digging into this=20 anyways, since we're going to need a customized installer for our site,=20= so if there is interest in this I can help out. Brian Davidson George Mason University From shadow@dementia.org Fri Mar 26 07:03:40 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 26 Mar 2004 02:03:40 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <02ee01c412ca$b17bc970$1909000a@ad.uiuc.edu> References: <02ee01c412ca$b17bc970$1909000a@ad.uiuc.edu> Message-ID: On Thu, 25 Mar 2004, Christopher D. Clausen wrote: > The exact same things occurs when one attempts to install the windows > AFS server using the new installer. I install everything and then have > to change the cell of my machine from openafs.org. I used the included > CellServDB. If I re-run the installer and don't select the AFS Server I > can then input a cell name. Doctor, when I turn my head and cough, it hurts. So don't do that. From jaltman@columbia.edu Fri Mar 26 07:18:50 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 25 Mar 2004 23:18:50 -0800 Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: References: <4063996B.5040600@columbia.edu> Message-ID: <4063D95A.9000608@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms050002000003090107080006 Content-Type: multipart/alternative; boundary="------------070705010005000005050807" This is a multi-part message in MIME format. --------------070705010005000005050807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brian Davidson wrote: > Has there been any thought given to removing the server pieces from > the installer? Even if it worked, it seems to me that 2 installers, > one for the client and one for the server, would be better. 99% of > the installs are going to be clients, not servers, so a client only > installer would be easiest for most users. > I have little interest in creating and supporting multiple installers. You can certainly for your site remove the Server functionality by deleting three lines of script code from the installer script. However, it is not something I intend to do for the versions distributed by OpenAFS.ORG. Instead my desire is to make the AFS Server work. If you are going to provide a custom installer, I suggest you also integrate the KFW NSIS scripts into the distribution. I do not have consensus yet as to whether or not, OpenAFS.ORG should do that with its installers. Or simply require people to install the MIT KFW installer before the OpenAFS.ORG installation. Jeffrey Altman --------------070705010005000005050807 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Brian Davidson wrote:
Has there been any thought given to removing the server pieces from the installer?  Even if it worked, it seems to me that 2 installers, one for the client and one for the server, would be better.  99% of the installs are going to be clients, not servers, so a client only installer would be easiest for most users.

I have little interest in creating and supporting multiple installers.  You can certainly for your site remove the Server functionality by deleting three lines of script code from the installer script.  However, it is not something I intend to do for the versions distributed by OpenAFS.ORG.  Instead my desire is to make the AFS Server work. 

If you are going to provide a custom installer, I suggest you also integrate the KFW NSIS scripts into the distribution. 
I do not have consensus yet as to whether or not, OpenAFS.ORG should do that with its installers.  Or simply require
people to install the MIT KFW installer before the OpenAFS.ORG installation.

Jeffrey Altman


--------------070705010005000005050807-- --------------ms050002000003090107080006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNjA3MTg1MFowIwYJKoZIhvcNAQkEMRYEFJBpy99hRmzU RRlbBrf3SEMvxILdMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAjC7Cb5a5OyjXycnZ9/9EhDHCikXv 1HKMGim/r6PI5bZUQNpdz8IiN3rtFZs3AJABztJ8fnfPM5bMVv0DvYAnY60K/eRqlQTSKmwR omGZTFFIlQnc8CbJKvMoKeptL0aQxTUAgOGKvxGOxXOe9OWkYFdKq+v4p8ouA9k04JF3fk/k kfAHN8+B0Oj8fvke7O2U1MzxnsSfSGOtB24psRTQCF+XzBUMWJ7Ww+E7jx5qKFqgpepcwT4z h2yLHggJgt8k5/TpZ6HSzjQQlSwZfGHzlWtcwORFzsWlDu8o56Af3zSbLqW2aB3YxWF34HFP Bdi888kHtRnd7eB0iVssspniXwAAAAAAAA== --------------ms050002000003090107080006-- From cclausen@acm.org Fri Mar 26 07:18:44 2004 From: cclausen@acm.org (Christopher D. Clausen) Date: Fri, 26 Mar 2004 01:18:44 -0600 Subject: [OpenAFS] Strange Windows Installer Issue References: <02ee01c412ca$b17bc970$1909000a@ad.uiuc.edu> Message-ID: <056601c41302$aee25f70$1909000a@ad.uiuc.edu> On Friday, March 26, 2004 1:03a wrote: > On Thu, 25 Mar 2004, Christopher D. Clausen wrote: > >> The exact same things occurs when one attempts to install the windows >> AFS server using the new installer. I install everything and then >> have to change the cell of my machine from openafs.org. I used the >> included CellServDB. If I re-run the installer and don't select the >> AFS Server I can then input a cell name. > > Doctor, when I turn my head and cough, it hurts. > > So don't do that. Yes, I see. I thought I would save myself some time and install both the client and server at the same time and then configure the server after the client is working. I now know not to do that, especially since the server apparently doesn't work all that well on Windows. < References: <02ee01c412ca$b17bc970$1909000a@ad.uiuc.edu> <056601c41302$aee25f70$1909000a@ad.uiuc.edu> Message-ID: On Fri, 26 Mar 2004, Christopher D. Clausen wrote: > >> have to change the cell of my machine from openafs.org. I used the > >> included CellServDB. If I re-run the installer and don't select the > >> AFS Server I can then input a cell name. > > > > Doctor, when I turn my head and cough, it hurts. > > > > So don't do that. > > Yes, I see. > > I thought I would save myself some time and install both the client and > server at the same time and then configure the server after the client > is working. I now know not to do that, especially since the server > apparently doesn't work all that well on Windows. It will. Just not this week. (Well, if you do stuff by hand, and not from the installer, you might get it working now, but it may not be much fun) From deengert@anl.gov Fri Mar 26 13:09:56 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Fri, 26 Mar 2004 07:09:56 -0600 Subject: [OpenAFS] Issues with KfW and OpenAFS References: <4063996B.5040600@columbia.edu> <4063D95A.9000608@columbia.edu> Message-ID: <40642BA4.24F46E3C@anl.gov> > Jeffrey Altman wrote: > > If you are going to provide a custom installer, I suggest you also integrate the KFW NSIS > scripts into the distribution. I do not have consensus yet as to whether or not, OpenAFS.ORG > should do that with its installers. Or simply require > people to install the MIT KFW installer before the OpenAFS.ORG installation. There is an important issue here. Will future versions of OpenAFS be dependent on KfW? Its fine that they can work together, but will KfW be required? What about other implementations of Kerberos including the version provided in Windows? I would hope that OpenAFS would not require a specific version of Kerberos. > > Jeffrey Altman -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman@columbia.edu Fri Mar 26 16:22:22 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Fri, 26 Mar 2004 08:22:22 -0800 Subject: [OpenAFS] Re: Issues with KfW and OpenAFS In-Reply-To: <40642BA4.24F46E3C@anl.gov> References: <4063996B.5040600@columbia.edu> <4063D95A.9000608@columbia.edu> <40642BA4.24F46E3C@anl.gov> Message-ID: <406458BE.2070308@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms080606050502070700010001 Content-Type: multipart/alternative; boundary="------------010502070106050204080201" This is a multi-part message in MIME format. --------------010502070106050204080201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Douglas E. Engert wrote: >There is an important issue here. Will future versions of OpenAFS be dependent >on KfW? > OpenAFS is not dependent on KFW. You can turn the use of KFW off on a local machine or current user basis if desired. However, if you want Kerberos 5 support integrated into the OpenAFS tools (system tray dialogs, aklog, integrated logon, etc) KFW is the way you get it. As you well know, the version of Kerberos provided in Windows does not have a clean API. Its behaviors have changed in each version of Windows. Via the MIT MSLSA: krb5_ccache type all of this is hidden. You are able to utilize both the Kerberos SSP and the MIT implementation in a uniform manner. All of the ugly details of the Kerberos SSP are hidden from view. Even if you could simply use the Kerberos SSP, you would still need a Kerberos library to support krb524d or something similar. Yes, I know about your desire to have your gssklogd be supported instead. However, that functionality is not packaged at the current time with either of the popular KDCs nor is it packaged with OpenAFS. My final argument is one of limited resources. The available resources are extremely limited. Not just from a funding perspective but from a developer perspective. Its not like we have had people jumping up and down desiring to perform development work on OpenAFS for Windows. I cannot justify the cost of re-implementing and maintaining the code necessary to utilize the Kerberos LSA on current and future platforms within OpenAFS when there is a library available which is supported and maintained which breaks the dependencies and provides an abstraction layer which allows OpenAFS to use Kerberos 5 seemlessly regardless of whether the Windows Logon Session is Kerberos 5 authenticated or not. So while MIT Kerberos for Windows is not required, I believe that from a practical perspective, for 99% of OpenAFS users on Windows it should be considered as if it were. Constructing a single NSIS installer which conditionally installs MIT KFW if it is not there is trivial given the fact that both OpenAFS and MIT KFW are using the NSIS scripts. Jeffrey Altman --------------010502070106050204080201 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Douglas E. Engert wrote:
There is an important issue here. Will future versions of OpenAFS be dependent
on KfW?  
OpenAFS is not dependent on KFW.  You can turn the use
of KFW off on a local machine or current user basis if
desired.  However, if you want Kerberos 5 support integrated
into the OpenAFS tools (system tray dialogs, aklog, integrated
logon, etc) KFW is the way you get it.

As you well know, the version of Kerberos provided in Windows does not have
a clean API.  Its behaviors have changed in each version of Windows.  Via
the MIT MSLSA: krb5_ccache type all of this is hidden.  You are able to
utilize both the Kerberos SSP and the MIT implementation in a uniform
manner.  All of the ugly details of the Kerberos SSP are hidden from view.

Even if you could simply use the Kerberos SSP, you would still need
a Kerberos library to support krb524d or something similar.  Yes, I know about
your desire to have your gssklogd be supported instead.  However, that
functionality is not packaged at the current time with either of the popular
KDCs nor is it packaged with OpenAFS. 

My final argument is one of limited resources.  The available resources
are extremely limited.  Not just from a funding perspective but from a
developer perspective.  Its not like we have had people jumping up and
down desiring to perform development work on OpenAFS for Windows.
I cannot justify the cost of re-implementing and maintaining the code
necessary to utilize the Kerberos LSA on current and future platforms
within OpenAFS when there is a library available which is supported
and maintained which breaks the dependencies and provides an abstraction
layer which allows OpenAFS to use Kerberos 5 seemlessly regardless of
whether the Windows Logon Session is Kerberos 5 authenticated or not.

So while MIT Kerberos for Windows is not required, I believe that from
a practical perspective, for 99% of OpenAFS users on Windows it should
be considered as if it were.  Constructing a single NSIS installer which
conditionally installs MIT KFW if it is not there is trivial given the fact
that both OpenAFS and MIT KFW are using the NSIS scripts.

Jeffrey Altman

--------------010502070106050204080201-- --------------ms080606050502070700010001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNjE2MjIyMlowIwYJKoZIhvcNAQkEMRYEFDqJF6laya3z rhxVvoUb3jNfJ9VGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAXnsL3BG77L82syUXX5xbZzvMVBUC e4q7YWQqoi6bApIAw3Gv7tMF4yIQL5UTaSonZ/Pw/koeSf2mDC23ux4+FTtCutE6MY0Wl5bY oYDcGL+AL+fXT2f778I2ZhYIVl43X9Ghc3FwdtY/YS25V7HSpgIcARZYtKPqVDvixVuiJ7Gx ncGhl0w/1LifkdSoLcBgznSWLH/p2wdDjPkbQC3NsE41nCcybus9LoXhj5riG+MVePmgGHy7 BTUrvslGKR1CvhnX3iHPnCYmT8UmWO/hjxmU2zM7JLeQNhdoai83uApeB4vh2hMCPuja9O7f FmR3qfY1M/LVh0NdBGXAPFBE8AAAAAAAAA== --------------ms080606050502070700010001-- From rsm4@ieee.org Fri Mar 26 00:52:39 2004 From: rsm4@ieee.org (Rob Murawski) Date: Thu, 25 Mar 2004 19:52:39 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <02ee01c412ca$b17bc970$1909000a@ad.uiuc.edu> Message-ID: On Thu, 25 Mar 2004, Christopher D. Clausen wrote: > The exact same things occurs when one attempts to install the windows > AFS server using the new installer. I install everything and then have > to change the cell of my machine from openafs.org. I used the included > CellServDB. If I re-run the installer and don't select the AFS Server I > can then input a cell name. This is by-design. When you install the "AFS Server" the cell may not exist yet--it is configured when the server configuration tool runs on the next reboot. (The cell name doesn't matter at that point) If a non-existent cell is set, the client will crash on startup. In this case, the client can start and the AFS server can be configured. Simply set your cell when you configure the server in the server configuration tool. All will be well. -Rob From deengert@anl.gov Fri Mar 26 21:33:33 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Fri, 26 Mar 2004 15:33:33 -0600 Subject: [OpenAFS] Re: Issues with KfW and OpenAFS References: <4063996B.5040600@columbia.edu> <4063D95A.9000608@columbia.edu> <40642BA4.24F46E3C@anl.gov> <406458BE.2070308@columbia.edu> Message-ID: <4064A1AD.62F786CC@anl.gov> > Jeffrey Altman wrote: > > Douglas E. Engert wrote: > > > There is an important issue here. Will future versions of OpenAFS be dependent > > on KfW? > > > OpenAFS is not dependent on KFW. You can turn the use > of KFW off on a local machine or current user basis if > desired. However, if you want Kerberos 5 support integrated > into the OpenAFS tools (system tray dialogs, aklog, integrated > logon, etc) KFW is the way you get it. Yes I agree. KfW gives you all the features and many people will use it. But it is another package to install or if installed with OpenAFS, doubles it size. > > As you well know, the version of Kerberos provided in Windows does not have > a clean API. Its behaviors have changed in each version of Windows. Via > the MIT MSLSA: krb5_ccache type all of this is hidden. You are able to > utilize both the Kerberos SSP and the MIT implementation in a uniform > manner. All of the ugly details of the Kerberos SSP are hidden from view. > > Even if you could simply use the Kerberos SSP, you would still need > a Kerberos library to support krb524d or something similar. krb524d can be eliminated if no mapping is needed between user@realm and user@cell, as the client can use the K5 ticket as the token using the kvno = RXKAD_TKT_TYPE_KERBEROS_V5 code. This is exactly what the msklog code I contributed to OpenAFS does. It can work with any KDC too. But due to the size if the ticket produced by a Microsoft AD AFS has problems. Microsoft had sent us a test fix for the problem, i.e. don't send the PAC in the service ticket, and they have been promising to release itas a hot fix any day. When this happens I will be geting back to msklog. > Yes, I know about your desire to have your gssklogd be supported instead. Its not instead, it is an alternative. And it can use the SSPI or the MIT gssapi, or any gssapi. > However, that > functionality is not packaged at the current time with either of the popular > KDCs nor is it packaged with OpenAFS. I did get gssklog built against 1.3.50 sometime ago, and now that you added the SDK changes to 1.3.61, it can be built using the SDK includes and libs. (It did take me a day and a half to get the VS .NET 2003 installed to build it.) > > My final argument is one of limited resources. The available resources > are extremely limited. Not just from a funding perspective but from a > developer perspective. Its not like we have had people jumping up and > down desiring to perform development work on OpenAFS for Windows. I think there are a lot of people that would like to help, but you are the only person I know of who really understands OpenAFS and Windows enough to get things done. Glad to see you working on it! > I cannot justify the cost of re-implementing and maintaining the code > necessary to utilize the Kerberos LSA on current and future platforms > within OpenAFS when there is a library available which is supported > and maintained which breaks the dependencies and provides an abstraction > layer which allows OpenAFS to use Kerberos 5 seemlessly regardless of > whether the Windows Logon Session is Kerberos 5 authenticated or not. Well when Microsoft finally releases that NOPAC for the ticket hot fix I am going to look closer at integrating the msklog code which uses the Kerberos LSA. The main subroutine with all the LSA code is only 365 lines of code. > > So while MIT Kerberos for Windows is not required, I believe that from > a practical perspective, for 99% of OpenAFS users on Windows it should > be considered as if it were. Constructing a single NSIS installer which > conditionally installs MIT KFW if it is not there is trivial given the fact > that both OpenAFS and MIT KFW are using the NSIS scripts. I think your estimate of 99% is high, but we will see. I know I will install it, at least for now. But I still think there are many users who would use OpenAFS in a AD who don't want to install the extra KfW package if they don't have to. > > Jeffrey Altman -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From alfw@slac.stanford.edu Fri Mar 26 23:20:08 2004 From: alfw@slac.stanford.edu (Alf Wachsmann) Date: Fri, 26 Mar 2004 15:20:08 -0800 (PST) Subject: [OpenAFS] Slides from AFS Best Practices Workshop Message-ID: Hi, the slides from all presentations given at the AFS Best Practices Workshop this week at SLAC are available online via the workshop's agenda web page: http://www-conf.slac.stanford.edu/AFSBestPractices/program.htm Enjoy, Alf. ----------------------------------------------------------------------- Alf Wachsmann | e-mail: alfw@slac.stanford.edu SLAC Computing Service | Phone: +1-650-926-4802 2575 Sand Hill Road, M/S 97 | FAX: +1-650-926-3329 Menlo Park, CA 94025, USA | Office: Bldg. 50/323 ----------------------------------------------------------------------- http://www.slac.stanford.edu/~alfw (PGP) ----------------------------------------------------------------------- From Thomas.Chung@jpl.nasa.gov Sat Mar 27 00:50:19 2004 From: Thomas.Chung@jpl.nasa.gov (Thomas Chung) Date: Fri, 26 Mar 2004 16:50:19 -0800 Subject: [OpenAFS] AFS filesystem size Message-ID: <1080348619.14223.3.camel@tchung-linux.jpl.nasa.gov> Hello, Here is my system info: Red Hat Enterpriese Linux 3 OpenAFS 1.2.11-rhel3.0.1 I can access to my AFS account fine but I've noticed the AFS filesystem size seems too small. I remember seeing 8 or 9 GB for AFS filesystem size on RHL 9. Here is my df -h # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda5 64G 3.7G 57G 7% / /dev/sda1 99M 15M 79M 16% /boot none 503M 0 503M 0% /dev/shm /dev/sda3 487M 10M 452M 3% /usr/vice/cache AFS 1.0K 0.0K 1.0K 0% /afs Is this normal in release 1.2.11? Thank you for your time. Thomas Chung From shadow@dementia.org Sat Mar 27 00:53:41 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 26 Mar 2004 19:53:41 -0500 (EST) Subject: [OpenAFS] AFS filesystem size In-Reply-To: <1080348619.14223.3.camel@tchung-linux.jpl.nasa.gov> References: <1080348619.14223.3.camel@tchung-linux.jpl.nasa.gov> Message-ID: On Fri, 26 Mar 2004, Thomas Chung wrote: > I can access to my AFS account fine but I've noticed the AFS filesystem > size seems too small. I remember seeing 8 or 9 GB for AFS filesystem > size on RHL 9. it's a faked number regardless, but that does sound suspect. From joezou@au1.ibm.com Sat Mar 27 12:20:20 2004 From: joezou@au1.ibm.com (Joe Zou) Date: Sat, 27 Mar 2004 23:20:20 +1100 Subject: [OpenAFS] Re:AFS 1.3.62 Linux Build Message-ID: This is a multipart message in MIME format. --=_alternative 004314A5CA256E64_= Content-Type: text/plain; charset="us-ascii" Hi guys, I have just downloaded the source and built AFS1.3.62 on the Red Hat Linux 7.2. Based on the Quick Start Guide, before configuring the AFS server, we need to run a startup script, which basically executes the 'insmod' command to load the AFS module. However, I could not find the startup script in the build destination directory. The document seems to indicate the script can be copied from the AFS CD. Question is if we build AFS from the source, how do we acquire the startup script? Does any one have the Linux startup script? Any help is appreciated. Cheers, Joe Zou I --=_alternative 004314A5CA256E64_= Content-Type: text/html; charset="us-ascii"
Hi guys,

I have just downloaded the source and built AFS1.3.62 on the Red Hat Linux 7.2.

Based on the Quick Start Guide, before configuring the AFS server, we need to run a startup script, which basically executes the 'insmod' command to load the AFS module. However, I could not find the startup script in the build destination directory. The document seems to indicate the script can be copied from the AFS CD. Question is if we build AFS from the source, how do we acquire the startup script?

Does any one have the Linux startup script?

Any help is appreciated.

Cheers,


Joe Zou
I
--=_alternative 004314A5CA256E64_=-- From warlord@MIT.EDU Sat Mar 27 14:28:21 2004 From: warlord@MIT.EDU (Derek Atkins) Date: Sat, 27 Mar 2004 09:28:21 -0500 Subject: [OpenAFS] Re:AFS 1.3.62 Linux Build In-Reply-To: (Joe Zou's message of "Sat, 27 Mar 2004 23:20:20 +1100") References: Message-ID: Did you "make dest"? Or did you "make install"? -derek Joe Zou writes: > Hi guys, > > I have just downloaded the source and built AFS1.3.62 on the Red Hat Linux 7.2. > > Based on the Quick Start Guide, before configuring the AFS server, we need to run a > startup script, which basically executes the 'insmod' command to load the AFS > module. However, I could not find the startup script in the build destination > directory. The document seems to indicate the script can be copied from the AFS CD. > Question is if we build AFS from the source, how do we acquire the startup script? > > Does any one have the Linux startup script? > > Any help is appreciated. > > Cheers, > > Joe Zou > I > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From james@burns.net Sat Mar 27 16:42:48 2004 From: james@burns.net (James Burns) Date: Sat, 27 Mar 2004 11:42:48 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <20040326170103.18CD59CB4@grand.central.org> Message-ID: I'd be willing to contribute some time to get the Windows server working if someone could point me in the right direction. Also if there's a document on the "by hand" way, I'd be grateful for the too. I set up my linux server that way and would be happy to do windows by hand as well. -James On Fri, 26 Mar 2004 openafs-info-request@openafs.org wrote: > --__--__-- > > Message: 3 > Date: Fri, 26 Mar 2004 02:21:14 -0500 (EST) > From: Derrick J Brashear > To: openafs-info@openafs.org > Subject: Re: [OpenAFS] Strange Windows Installer Issue > > On Fri, 26 Mar 2004, Christopher D. Clausen wrote: > > > >> have to change the cell of my machine from openafs.org. I used the > > >> included CellServDB. If I re-run the installer and don't select the > > >> AFS Server I can then input a cell name. > > > > > > Doctor, when I turn my head and cough, it hurts. > > > > > > So don't do that. > > > > Yes, I see. > > > > I thought I would save myself some time and install both the client and > > server at the same time and then configure the server after the client > > is working. I now know not to do that, especially since the server > > apparently doesn't work all that well on Windows. > > It will. Just not this week. (Well, if you do stuff by hand, and not from > the installer, you might get it working now, but it may not be much fun) > > From jhutz@cmu.edu Sat Mar 27 16:53:26 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Sat, 27 Mar 2004 11:53:26 -0500 Subject: [OpenAFS] Re:AFS 1.3.62 Linux Build In-Reply-To: References: Message-ID: <308210000.1080406406@minbar.fac.cs.cmu.edu> On Saturday, March 27, 2004 23:20:20 +1100 Joe Zou wrote: > Hi guys, > > I have just downloaded the source and built AFS1.3.62 on the Red Hat > Linux 7.2. > > Based on the Quick Start Guide, before configuring the AFS server, we > need to run a startup script, which basically executes the 'insmod' > command to load the AFS module. However, I could not find the startup > script in the build destination directory. The document seems to > indicate the script can be copied from the AFS CD. Question is if we > build AFS from the source, how do we acquire the startup script? That depends. If you did a 'make dest', it's in root.client/usr/vice/etc/afs.dc If you did a 'make install', it didn't get installed, but you can copy it from src/afsd/afs.rc.linux In any case, you do not need to load the kernel module before starting a fileserver on a Linux system. That requirement exists only for systems which use the inode fileserver. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From jaltman@columbia.edu Sat Mar 27 17:15:26 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sat, 27 Mar 2004 11:15:26 -0600 Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: References: Message-ID: <4065B6AE.7000407@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms050800040107070906030804 Content-Type: multipart/alternative; boundary="------------010209080302030707080001" This is a multi-part message in MIME format. --------------010209080302030707080001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Grab the sources out of the CVS and start debugging. That is what I am doing. James Burns wrote: >I'd be willing to contribute some time to get the Windows server working >if someone could point me in the right direction. Also if there's a >document on the "by hand" way, I'd be grateful for the too. I set up my >linux server that way and would be happy to do windows by hand as well. > >-James > --------------010209080302030707080001 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Grab the sources out of the CVS and start debugging.
That is what I am doing.



James Burns wrote:
I'd be willing to contribute some time to get the Windows server working 
if someone could point me in the right direction. Also if there's a 
document on the "by hand" way, I'd be grateful for the too. I set up my 
linux server that way and would be happy to do windows by hand as well.

-James
--------------010209080302030707080001-- --------------ms050800040107070906030804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNzE3MTUyNlowIwYJKoZIhvcNAQkEMRYEFElvHsaZBsrW H8kg8nLincLArTDQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAiDm2RUxN5T10QoARlbSnFtAjmmqS pUBPjXE5CObOolYkfAkwKUSVGLORz15q9/twrsydhoyE5Oni4P8gwYDdEIFaOEkXSlNoYdT8 L5uGyJvVLg/8GS0OW/29Kxsv9Fzj2m1eX4q7JOHfUY5xJwVIy0xLFbvgtAxXjwhhdP0aQqnW 5s8m5AH4OHmz41e75gRyHP+rVKOi391sDBg1GL+cUj1Mg9+jdIIihxA7+ZJZSzo+vkuhlqiy GUUGurn5uYryjYHrCQPm2Y+C5HdBaarBo5qqnsXciXZp4R2cFWcc1NBHDnfo27GVhpTJItTl hmnEqEqR+ykrfuCv29lA4qFUBQAAAAAAAA== --------------ms050800040107070906030804-- From sturdiva@umd.edu Sat Mar 27 20:11:35 2004 From: sturdiva@umd.edu (Eric Sturdivant) Date: Sat, 27 Mar 2004 15:11:35 -0500 (EST) Subject: [OpenAFS] AFS filesystem size In-Reply-To: <1080348619.14223.3.camel@tchung-linux.jpl.nasa.gov> Message-ID: On Fri, 26 Mar 2004, Thomas Chung wrote: > Hello, > > Here is my system info: > > Red Hat Enterpriese Linux 3 > OpenAFS 1.2.11-rhel3.0.1 > > I can access to my AFS account fine but I've noticed the AFS filesystem > size seems too small. I remember seeing 8 or 9 GB for AFS filesystem > size on RHL 9. > > Here is my df -h > > # df -h > Filesystem Size Used Avail Use% Mounted on > /dev/sda5 64G 3.7G 57G 7% / > /dev/sda1 99M 15M 79M 16% /boot > none 503M 0 503M 0% /dev/shm > /dev/sda3 487M 10M 452M 3% /usr/vice/cache > AFS 1.0K 0.0K 1.0K 0% /afs > > Is this normal in release 1.2.11? > > Thank you for your time. > > Thomas Chung > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > We had a similar problem under rehdat enterprise 3, but the filesystem size for AFS was negative. Turned out to be a problem between the kernel version and the libc version. The following patch (against 1.2.11) correct the problem for us. @@ -325,6 +325,8 @@ stat.f_fsid.val[0] = AFS_VFSMAGIC; stat.f_fsid.val[1] = AFS_VFSFSID; stat.f_namelen = 256; + /* to fake the user space f_frsize member being 0 */ + memset(stat.f_spare, 0, sizeof(stat.f_spare)); #if defined(AFS_LINUX24_ENV) *statp = stat; -- Eric Sturdivant University of Maryland Office of Information Technology Distributed Computing Services (301) 405-8473 sturdiva@umd.edu http://www.oit.umd.edu/dcs From james@burns.net Sat Mar 27 21:40:41 2004 From: james@burns.net (James Burns) Date: Sat, 27 Mar 2004 16:40:41 -0500 (EST) Subject: [OpenAFS] Strange Windows Installer Issue In-Reply-To: <4065B6AE.7000407@columbia.edu> Message-ID: You build with VS.NET 2003? It's too bad it's so fricking huge... I'll check it out, see if I can figure out what's going on with this first error. -James On Sat, 27 Mar 2004, Jeffrey Altman wrote: > Grab the sources out of the CVS and start debugging. > That is what I am doing. > > > > James Burns wrote: > > >I'd be willing to contribute some time to get the Windows server working > >if someone could point me in the right direction. Also if there's a > >document on the "by hand" way, I'd be grateful for the too. I set up my > >linux server that way and would be happy to do windows by hand as well. > > > >-James > > > From stephen@physics.unc.edu Sun Mar 28 17:40:04 2004 From: stephen@physics.unc.edu (Stephen Joyce) Date: Sun, 28 Mar 2004 12:40:04 -0500 (EST) Subject: [OpenAFS] Solaris servers and >1TB disks Message-ID: I'm planning to add a new Solaris9 fileserver to my cell with an attached raid of 1.4TB. I see that as of Solaris 9 8/03, ufs filesystems of over 1TB are supported, but that the format of the disk labels has changed (EFI, Extensible Firmware Interface: http://docs.sun.com/db/doc/817-0493/6mg9pruaf?q=efi&a=view ). Up until now, my largest fileserver had ~450GB on it. Luckily I've only had a fsck/salvage situation on one of the 450GB servers once in 2 years and it only took ~25 mins. So... Can anyone confirm that the Solaris OpenAFS inode server will function normally on a >1TB ufs, but EFI labelled, disk (I'm planning 7 200GB partitions)? I'm assume so, but am uncertain enough to ask. Multiple LUNs of less than 1TB each are another option. Should I just ditch the inode server and go with the namei server on Solaris (so that I can turn on logging to reduce the need for fscks)? I think I remember reading that there's a not-insignificant performance penalty between inode and namei, but I can't seem to find that info right now. Cheers, Stephen -- Stephen Joyce Systems Administrator P A N I C Physics & Astronomy Department Physics & Astronomy University of North Carolina at Chapel Hill Network Infrastructure voice: (919) 962-7214 and Computing fax: (919) 962-0480 http://www.panic.unc.edu When solving a system "panic", you must first ask yourself what you were doing that could possibly frighten an operating system. From alfw@slac.stanford.edu Sun Mar 28 18:27:11 2004 From: alfw@slac.stanford.edu (Alf Wachsmann) Date: Sun, 28 Mar 2004 10:27:11 -0800 (PST) Subject: [OpenAFS] Solaris servers and >1TB disks In-Reply-To: References: Message-ID: On Sun, 28 Mar 2004, Stephen Joyce wrote: > Can anyone confirm that the Solaris OpenAFS inode server will > function normally on a >1TB ufs, but EFI labelled, disk (I'm planning 7 > 200GB partitions)? I'm assume so, but am uncertain enough to ask. Multiple > LUNs of less than 1TB each are another option. See https://lists.openafs.org/pipermail/openafs-info/2004-March/012514.html The answer: it does not work (yet). > Should I just ditch the inode server and go with the namei server > on Solaris (so that I can turn on logging to reduce the need for fscks)? I > think I remember reading that there's a not-insignificant performance > penalty between inode and namei, but I can't seem to find that info right > now. I have done some performance testing with Solaris 9 on x86 and saw a some performance difference between inode and namei but it depends on the profile of your applications. See http://grand.central.org/twiki/bin/view/AFSLore/PerformanceWork -- Alf. ----------------------------------------------------------------------- Alf Wachsmann | e-mail: alfw@slac.stanford.edu SLAC Computing Service | Phone: +1-650-926-4802 2575 Sand Hill Road, M/S 97 | FAX: +1-650-926-3329 Menlo Park, CA 94025, USA | Office: Bldg. 50/323 ----------------------------------------------------------------------- http://www.slac.stanford.edu/~alfw (PGP) ----------------------------------------------------------------------- From janus@bananus.dk Sun Mar 28 22:22:37 2004 From: janus@bananus.dk (Janus N. =?ISO-8859-1?Q?T=F8ndering?=) Date: Mon, 29 Mar 2004 00:22:37 +0200 Subject: [OpenAFS] AFS client/server problem Message-ID: <1080512555.2551.2.camel@apple.bananus.dk> Hi, I have been trying to setup an AFS server on my local network and I am having some problems reaching the AFS server from other machines on the network. When I issue klog on a client machine I get the following answer: "Unable to authenticate to AFS because Authentication Server was unavailable". On the serverside I get: tcpdump udp and host tcpdump: listening on eth0 04:15:02.493926 .32793 > .afs3-kaserver: rx data kauth call authenticate-v2 principal "admin" "" (76) (DF) 04:15:02.493988 .afs3-kaserver > .32793: rx abort kauth reply authenticate-v2 errcode 180514 (32) (DF) 04:15:05.674436 .32793 > .afs3-kaserver: rx data kauth call authenticate-v2 principal "admin" "" (76) (DF) 04:15:05.674904 .afs3-kaserver > .32793: rx abort kauth reply authenticate-v2 errcode 180514 (32) (DF) 04:15:07.674664 .32793 > .afs3-kaserver: rx data kauth call authenticate-v2 principal "admin" "" (76) (DF) 04:15:07.674754 .afs3-kaserver > .32793: rx abort kauth reply authenticate-v2 errcode 180514 (32) (DF) 04:15:09.935100 .32793 > .afs3-kaserver: rx data kauth call authenticate-v2 principal "admin" "" (76) (DF) 04:15:09.935170 .afs3-kaserver > .32793: rx abort kauth reply authenticate-v2 errcode 180514 (32) (DF) 04:15:12.705774 .32793 > .afs3-kaserver: rx data kauth call authenticate-v2 principal "admin" "" (76) (DF) 04:15:12.705844 .afs3-kaserver > .32793: rx abort kauth reply authenticate-v2 errcode 180514 (32) (DF) 04:15:15.696017 .32793 > .afs3-kaserver: rx ack (65) (DF) 04:15:15.696091 .afs3-kaserver > .32793: rx abort kauth reply authenticate-v2 errcode 180514 (32) (DF) 04:15:16.506765 .32793 > .afs3-kaserver: rx data kauth call authenticate-v2 principal "admin" "" (76) (DF) 04:15:16.506825 .afs3-kaserver > .32793: rx abort kauth reply authenticate-v2 errcode 180514 (32) (DF) bos status: Instance kaserver, currently running normally. Instance buserver, currently running normally. Instance ptserver, currently running normally. Instance vlserver, currently running normally. Instance fs, currently running normally. Auxiliary status is: file server running. Instance upserver, currently running normally. What am I missing here? -Janus --=20 Janus N. T=F8ndering GPG Fingerprint: 4035 778C 4868 25C6 D23E 175A 8593 AEFF 7145 2196 From marena23@hotmail.com Sun Mar 28 22:55:00 2004 From: marena23@hotmail.com (Michael Arena) Date: Sun, 28 Mar 2004 17:55:00 -0500 Subject: [OpenAFS] Newbie Question Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C414ED.C9F33360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I'm trying to install OpenAFS version 1.2.11 on Fedora Core 1 and am = having some problems setting it up which the install doc didn't address. = I unpack the source and run configure, make and make install with no = errors. However the doc doesn't say what the next step should be, it = just talks about starting the bosserver which I tried to do but is = giving me an error "Problem with /usr/local/var/logs/openafs Server = Directory access is okay" I'm assuming I'm missing a step in order to complete the configuration, = can anyone lend any advice or more thorough documentation so I can set = this up and begin testing it out. Thanks in advance, Mike ------=_NextPart_000_0045_01C414ED.C9F33360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
I'm trying to install OpenAFS version=20 1.2.11 on Fedora Core 1 and am having some problems setting it up = which the=20 install doc didn't address. I unpack the source and run configure, make = and make=20 install with no errors. However the doc doesn't say what the next step = should=20 be, it just talks about starting the bosserver which I tried to do but = is giving=20 me an error "Problem with /usr/local/var/logs/openafs Server Directory = access is=20 okay"
 
I'm assuming I'm missing a step in = order to=20 complete the configuration, can anyone lend any advice or more thorough=20 documentation so I can set this up and begin testing it = out.
 
Thanks in advance,
Mike
------=_NextPart_000_0045_01C414ED.C9F33360-- From boeheim@slac.stanford.edu Sun Mar 28 23:30:30 2004 From: boeheim@slac.stanford.edu (Chuck Boeheim) Date: Sun, 28 Mar 2004 15:30:30 -0800 Subject: [OpenAFS] afsd crash in 1.3.62 Message-ID: <40676016.4010907@slac.stanford.edu> The 1.3.62 release has been much more stable for me than previous releases, but I just got the following crash on my windows XP system while navigating to an AFS directory from an open dialog: 3/28/2004 3:06:59 PM: UnhandledException : code : 0xc0000005, address: 0x61093bc8 --# FV EIP----- RetAddr- FramePtr StackPtr Symbol 0 .V 61093bc8 6108dbf5 02f4be18 00000000 rxkad_GetServerInfo +2210 bytes 1 .V 6108dbf5 6108f21a 02f4be38 00000000 hton_syserr_conv +6663 bytes 2 .V 6108f21a 6108f379 02f4be58 00000000 rx_WriteProc +732 bytes 3 .V 6108f379 6108f789 02f4be84 00000000 rx_FlushWrite +306 bytes 4 .V 6108f789 00407b6e 02f4bea8 00000000 rx_ReadProc +187 bytes 5 .V 00407b6e 00409500 02f4bfb4 00000000 6 .V 00409500 0040a84a 02f4c004 00000000 7 .V 0040a84a 00415cd5 02f4f6a4 00000000 8 .V 00415cd5 004145d9 02f4f78c 00000000 9 .V 004145d9 00411949 02f4f7e4 00000000 10 .V 00411949 00413329 02f4f9cc 00000000 11 .V 00413329 77e7d33b 02f4ffb4 00000000 12 .V 77e7d33b 00000000 02f4ffec 00000000 RegisterWaitForInputIdle +67 bytes Is there any other information that would help? From dhk@ccre.com Mon Mar 29 00:01:41 2004 From: dhk@ccre.com (Dexter 'Kim' Kimball) Date: Sun, 28 Mar 2004 17:01:41 -0700 Subject: [OpenAFS] Newbie Question In-Reply-To: Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C414E6.57B43D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mike, I've been doing this a long time and generally forget something. I therefore recommend: http://www.openafs.org/pages/doc/QuickStartUnix/auqbg002.htm After you finish the generic scripts, search for "Getting Started on Linux Systems" for the Linux specific stuff. Kim -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]On Behalf Of Michael Arena Sent: Sunday, March 28, 2004 3:55 PM To: openafs-info@openafs.org Subject: [OpenAFS] Newbie Question Hello all, I'm trying to install OpenAFS version 1.2.11 on Fedora Core 1 and am having some problems setting it up which the install doc didn't address. I unpack the source and run configure, make and make install with no errors. However the doc doesn't say what the next step should be, it just talks about starting the bosserver which I tried to do but is giving me an error "Problem with /usr/local/var/logs/openafs Server Directory access is okay" I'm assuming I'm missing a step in order to complete the configuration, can anyone lend any advice or more thorough documentation so I can set this up and begin testing it out. Thanks in advance, Mike ------=_NextPart_000_0066_01C414E6.57B43D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mike,
 
 
I've=20 been doing this a long time and generally forget something.  I = therefore=20 recommend:
 
htt= p://www.openafs.org/pages/doc/QuickStartUnix/auqbg002.htm
 
After=20 you finish the generic scripts, search for "Getting Started on Linux=20 Systems"  for the Linux specific stuff.
 
 
Kim
 
 
-----Original Message-----
From:=20 openafs-info-admin@openafs.org = [mailto:openafs-info-admin@openafs.org]On=20 Behalf Of Michael Arena
Sent: Sunday, March 28, 2004 = 3:55=20 PM
To: openafs-info@openafs.org
Subject: [OpenAFS] = Newbie=20 Question

Hello all,
I'm trying to install OpenAFS version = 1.2.11 on Fedora Core 1 and am having some problems setting it up = which=20 the install doc didn't address. I unpack the source and run configure, = make=20 and make install with no errors. However the doc doesn't say what the = next=20 step should be, it just talks about starting the bosserver which I = tried to do=20 but is giving me an error "Problem with /usr/local/var/logs/openafs = Server=20 Directory access is okay"
 
I'm assuming I'm missing a step in = order to=20 complete the configuration, can anyone lend any advice or more = thorough=20 documentation so I can set this up and begin testing it = out.
 
Thanks in advance,
Mike
------=_NextPart_000_0066_01C414E6.57B43D00-- From shadow@dementia.org Mon Mar 29 01:40:22 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Sun, 28 Mar 2004 20:40:22 -0500 (EST) Subject: [OpenAFS] AFS client/server problem In-Reply-To: <1080512555.2551.2.camel@apple.bananus.dk> References: <1080512555.2551.2.camel@apple.bananus.dk> Message-ID: On Mon, 29 Mar 2004, Janus N. [ISO-8859-1] Tøndering wrote: > When I issue klog on a client machine I get the following > answer: > "Unable to authenticate to AFS because Authentication Server was > unavailable". what's in the AuthLog on the server? > On the serverside I get: > tcpdump udp and host > tcpdump: listening on eth0 > 04:15:02.493926 .32793 > .afs3-kaserver: rx data kauth > call authenticate-v2 principal "admin" "" (76) (DF) > 04:15:02.493988 .afs3-kaserver > .32793: rx abort kauth > reply authenticate-v2 errcode 180514 (32) (DF) 8:39pm:shadow@johnstown:sieve:177> translate_et 180514 180514 (ka).34 = server and client clocks are badly skewed > What am I missing here? Probably ntp. From jaltman@columbia.edu Mon Mar 29 02:22:08 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Sun, 28 Mar 2004 20:22:08 -0600 Subject: [OpenAFS] afsd crash in 1.3.62 In-Reply-To: <40676016.4010907@slac.stanford.edu> References: <40676016.4010907@slac.stanford.edu> Message-ID: <40678850.1080604@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms080000000106070506030207 Content-Type: multipart/alternative; boundary="------------000306070809080307080705" This is a multi-part message in MIME format. --------------000306070809080307080705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chuck Boeheim wrote: > The 1.3.62 release has been much more stable for me than previous > releases, but I just > got the following crash on my windows XP system while navigating to an > AFS directory > from an open dialog: > > 3/28/2004 3:06:59 PM: UnhandledException : code : 0xc0000005, address: > 0x61093bc8 > > > --# FV EIP----- RetAddr- FramePtr StackPtr Symbol > 0 .V 61093bc8 6108dbf5 02f4be18 00000000 rxkad_GetServerInfo +2210 bytes > 1 .V 6108dbf5 6108f21a 02f4be38 00000000 hton_syserr_conv +6663 bytes > 2 .V 6108f21a 6108f379 02f4be58 00000000 rx_WriteProc +732 bytes > 3 .V 6108f379 6108f789 02f4be84 00000000 rx_FlushWrite +306 bytes > 4 .V 6108f789 00407b6e 02f4bea8 00000000 rx_ReadProc +187 bytes > 5 .V 00407b6e 00409500 02f4bfb4 00000000 > 6 .V 00409500 0040a84a 02f4c004 00000000 > 7 .V 0040a84a 00415cd5 02f4f6a4 00000000 > 8 .V 00415cd5 004145d9 02f4f78c 00000000 > 9 .V 004145d9 00411949 02f4f7e4 00000000 > 10 .V 00411949 00413329 02f4f9cc 00000000 > 11 .V 00413329 77e7d33b 02f4ffb4 00000000 > 12 .V 77e7d33b 00000000 02f4ffec 00000000 RegisterWaitForInputIdle +67 > bytes > > Is there any other information that would help? yes, the %WINDIR%\TEMP\afsd.log file from the time of the crash. It will provide the filename and line number of the crash. Please file this as a bug in the openafs request tracker. Jeffrey Altman --------------000306070809080307080705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Chuck Boeheim wrote:
The 1.3.62 release has been much more stable for me than previous releases, but I just
got the following crash on my windows XP system while navigating to an AFS directory
from an open dialog:

3/28/2004 3:06:59 PM: UnhandledException : code : 0xc0000005, address: 0x61093bc8


--# FV EIP----- RetAddr- FramePtr StackPtr Symbol
 0 .V 61093bc8 6108dbf5 02f4be18 00000000 rxkad_GetServerInfo +2210 bytes
 1 .V 6108dbf5 6108f21a 02f4be38 00000000 hton_syserr_conv +6663 bytes
 2 .V 6108f21a 6108f379 02f4be58 00000000 rx_WriteProc +732 bytes
 3 .V 6108f379 6108f789 02f4be84 00000000 rx_FlushWrite +306 bytes
 4 .V 6108f789 00407b6e 02f4bea8 00000000 rx_ReadProc +187 bytes
 5 .V 00407b6e 00409500 02f4bfb4 00000000
 6 .V 00409500 0040a84a 02f4c004 00000000
 7 .V 0040a84a 00415cd5 02f4f6a4 00000000
 8 .V 00415cd5 004145d9 02f4f78c 00000000
 9 .V 004145d9 00411949 02f4f7e4 00000000
10 .V 00411949 00413329 02f4f9cc 00000000
11 .V 00413329 77e7d33b 02f4ffb4 00000000
12 .V 77e7d33b 00000000 02f4ffec 00000000 RegisterWaitForInputIdle +67 bytes

Is there any other information that would help?
yes, the %WINDIR%\TEMP\afsd.log file from the time of the crash.  It will
provide the filename and line number of the crash.

Please file this as a bug in the openafs request tracker. 

Jeffrey Altman

--------------000306070809080307080705-- --------------ms080000000106070506030207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMyOTAyMjIwOFowIwYJKoZIhvcNAQkEMRYEFDaQzXryBz/R mRcmNJyUTOhT+GwsMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEARpcP+SnBGpmuE+1ekmJtqmhwQRFi 1Pljt8ylt6OLmptRhefTvCORwhvJEXmcgUD2FFiPViqAeZWz5/QbWDNNmFSFnf8le3ADfF0p Qxt7/Oz1APDmoAG0M9+bMND6cCJPhGl+Af9h8al9pAmnYlsnOoZoKjDRO6RfRxCGSuY808hs AAvXYhaQUHjvR4kIk6vGLXW6aLmTbfS3geU2868EoSmSI8wfnm+XVPdCWpayHvbPN2395Cmd X42mIKVSIlM/cpTMuJiG1Sh+VngqndnvfMb158AR1RM+z876UeTS8UDIJN64AbBnJMoSc5j3 pi92+wqwv0j9rwvRFZDxUwgcwAAAAAAAAA== --------------ms080000000106070506030207-- From maduser@linux.net Mon Mar 29 13:06:16 2004 From: maduser@linux.net (Arthur Grotz) Date: Mon, 29 Mar 2004 05:06:16 -0800 (PST) Subject: [OpenAFS] (no subject) Message-ID: <20040329130616.9F8AE725F@sitemail.everyone.net> Helo I have installed openafs on debian 3.0, everything runs great untill I tried start afsd, i had these errors. >afsd: All AFS daemons started. >afsd: Can't mount AFS on /afs(22) (/afs is already created on disk.) Debian openafs installation is little different from the others, config files were installed in different directories and nowhere in the internet i couldn't found correct documentation, and i have a lot of troubles to set it up correctly. Does anyone know what these erros means and how to solve this problem ? _____________________________________________________________ Linux.Net -->Open Source to everyone Powered by Linare Corporation http://www.linare.com/ From janus@bananus.dk Mon Mar 29 13:45:36 2004 From: janus@bananus.dk (Janus N. =?ISO-8859-1?Q?T=F8ndering?=) Date: Mon, 29 Mar 2004 15:45:36 +0200 Subject: [OpenAFS] AFS client/server problem In-Reply-To: References: <1080512555.2551.2.camel@apple.bananus.dk> Message-ID: <1080567936.2551.5.camel@apple.bananus.dk> On Mon, 2004-03-29 at 03:40, Derrick J Brashear wrote: > On Mon, 29 Mar 2004, Janus N. [ISO-8859-1] T=F8ndering wrote: >=20 > > When I issue klog on a client machine I get the following > > answer: > > "Unable to authenticate to AFS because Authentication Server was > > unavailable". >=20 > what's in the AuthLog on the server? It didn't show anything. >=20 > > On the serverside I get: > > tcpdump udp and host > > tcpdump: listening on eth0 > > 04:15:02.493926 .32793 > .afs3-kaserver: rx data kauth > > call authenticate-v2 principal "admin" "" (76) (DF) > > 04:15:02.493988 .afs3-kaserver > .32793: rx abort kaut= h > > reply authenticate-v2 errcode 180514 (32) (DF) >=20 > 8:39pm:shadow@johnstown:sieve:177> translate_et 180514 > 180514 (ka).34 =3D server and client clocks are badly skewed >=20 > > What am I missing here? >=20 > Probably ntp. D'oh. Thanks a lot. This actually made it work. Regards, Janus N. T=F8ndering --=20 Janus N. T=F8ndering GPG Fingerprint: 4035 778C 4868 25C6 D23E 175A 8593 AEFF 7145 2196 From mturk@astro.psu.edu Mon Mar 29 14:45:46 2004 From: mturk@astro.psu.edu (Matthew Turk) Date: Mon, 29 Mar 2004 09:45:46 -0500 (EST) Subject: [OpenAFS] 'no space left on device' while importing Message-ID: Hi there. After taking everyone's suggestions carefully into consideration, I devised a volume system layout that I think works quite nicely for our overall system design. However, now I'm having trouble importing our existing filesystems. I've started making an infrastructure of user volumes; for the file system importing stage, I've set the quotas to 0/'no limit.' Whenever I try to scp files over directly to the server with the afs volume, and into the mountpoint for that volume, it copies for a few (coincidentally -- or not? -- up to the size of the cache) and then throws "no space left on device" for the current file, and the rest fail because of "input/output error." If I just place those files in the mountpoint on my afs file system, it copies up to the size of hte two caches combined and throws the same set of errors. What am I doing wrong? Are my caches not able to keep up for some reason? This is all fairly new to me -- but I do know that if I don't get this set up right, AFS may not be suitable for some of the tasks we intend to ask of it. Thanks for any help! mjt From TedAnderson@mindspring.com Mon Mar 29 15:12:30 2004 From: TedAnderson@mindspring.com (Ted Anderson) Date: Mon, 29 Mar 2004 10:12:30 -0500 Subject: [OpenAFS] 'no space left on device' while importing In-Reply-To: References: Message-ID: <40683CDE.1030807@mindspring.com> On 3/29/2004 09:45, Matthew Turk wrote: > Whenever I try to scp files over directly to the server with the afs > volume, and into the mountpoint for that volume, it copies for a few > (coincidentally -- or not? -- up to the size of the cache) and then throws > "no space left on device" for the current file, and the rest fail because > of "input/output error." If I just place those files in the mountpoint on > my afs file system, it copies up to the size of hte two caches combined > and throws the same set of errors. My guess is that your AFS client's cache is filling up the disk on which it is located. Ideally, you should put the cache in its own partition, but in any case you need to make sure the size specified in the cacheinfo file (/usr/vice/etc) is small enough that it can be held in the disk on which /usr/vice/cache exists. Try these two commands: % cat /usr/vice/etc/cacheinfo /afs:/usr/vice/cache:100000 % df -k /usr/vice/cache Filesystem 1k-blocks Used Available Use% Mounted on /dev/hdc3 18492060 3473932 14078776 20% / The size in cacheinfo is in KB, so in my example I need 100MB free in /. What are your numbers? Ted Anderson From mturk@astro.psu.edu Mon Mar 29 15:20:16 2004 From: mturk@astro.psu.edu (Matthew Turk) Date: Mon, 29 Mar 2004 10:20:16 -0500 (EST) Subject: [OpenAFS] 'no space left on device' while importing In-Reply-To: <40683CDE.1030807@mindspring.com> Message-ID: > My guess is that your AFS client's cache is filling up the disk on which > it is located. Ideally, you should put the cache in its own partition, > but in any case you need to make sure the size specified in the > cacheinfo file (/usr/vice/etc) is small enough that it can be held in > the disk on which /usr/vice/cache exists. Try these two commands: > > % cat /usr/vice/etc/cacheinfo > /afs:/usr/vice/cache:100000 > % df -k /usr/vice/cache > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/hdc3 18492060 3473932 14078776 20% / > > The size in cacheinfo is in KB, so in my example I need 100MB free in /. > What are your numbers? > # cat /usr/vice/cache /afs:/usr/vice/cache:3575203 # df -k /usr/vice/cache Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda7 3763372 3572204 0 100% /usr/vice/cache But, df -h reports: Filesystem Size Used Avail Use% Mounted on /dev/hda7 3.6G 3.5G 0 100% /usr/vice/cache Maybe this is too big? Should I just start my cache over? mjt From hendrik.hoeth@cern.ch Mon Mar 29 15:27:20 2004 From: hendrik.hoeth@cern.ch (Hendrik Hoeth) Date: Mon, 29 Mar 2004 17:27:20 +0200 Subject: [OpenAFS] 'no space left on device' while importing In-Reply-To: References: <40683CDE.1030807@mindspring.com> Message-ID: <20040329152720.GG13398@mail.physik.uni-wuppertal.de> Thus spake Matthew Turk (mturk@astro.psu.edu): > # cat /usr/vice/cache > /afs:/usr/vice/cache:3575203 ^^^^^^^ This seems quite large for the size of your partition. Try something like 90% of the partition size, e.g. 3350000. -- for (Int_t j = 0; j < 100; j++){ // ROOT Users Guide 3.10, p. 243 if (j < 100){ smallHisto->Fill(fTracks_fPx[j]); } } From openafs-info.lists@tisc.de Mon Mar 29 15:28:13 2004 From: openafs-info.lists@tisc.de (Tino Schwarze) Date: Mon, 29 Mar 2004 17:28:13 +0200 Subject: [OpenAFS] 'no space left on device' while importing In-Reply-To: References: <40683CDE.1030807@mindspring.com> Message-ID: <20040329152813.GD28819@easy.in-chemnitz.de> On Mon, Mar 29, 2004 at 10:20:16AM -0500, Matthew Turk wrote: > # cat /usr/vice/cache > /afs:/usr/vice/cache:3575203 > # df -k /usr/vice/cache > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda7 3763372 3572204 0 100% /usr/vice/cache > > But, df -h reports: > > Filesystem Size Used Avail Use% Mounted on > /dev/hda7 3.6G 3.5G 0 100% /usr/vice/cache > > Maybe this is too big? Should I just start my cache over? There used to be a magic number of about 90%, so lower it to 3387000 or so... I don't think that it will make a difference.. Bye, Tino. From jhutz@cmu.edu Mon Mar 29 15:27:23 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 29 Mar 2004 10:27:23 -0500 Subject: [OpenAFS] Solaris servers and >1TB disks In-Reply-To: References: Message-ID: <1540498928.1080574043@mariner.pc.cs.cmu.edu> On Sunday, March 28, 2004 10:27:11 -0800 Alf Wachsmann wrote: > On Sun, 28 Mar 2004, Stephen Joyce wrote: >> Can anyone confirm that the Solaris OpenAFS inode server will >> function normally on a >1TB ufs, but EFI labelled, disk (I'm planning 7 >> 200GB partitions)? I'm assume so, but am uncertain enough to ask. >> Multiple LUNs of less than 1TB each are another option. > > See > https://lists.openafs.org/pipermail/openafs-info/2004-March/012514.html > The answer: it does not work (yet). Not quite. A >1TB filesystem as a vice partition won't work, because vfsck doesn't understand the modified filesystem structure required to support this. We're working with Sun on getting this situation resolved. But what Stephen is asking about is several smaller filesystems on a >1TB _disk_ (i.e. a RAID array). I see no reason why that shouldn't work; none of our code (including vfsck) knows anything about disk labels. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From jhutz@cmu.edu Mon Mar 29 15:35:52 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 29 Mar 2004 10:35:52 -0500 Subject: [OpenAFS] 'no space left on device' while importing In-Reply-To: References: Message-ID: <1541638928.1080574552@mariner.pc.cs.cmu.edu> On Monday, March 29, 2004 10:20:16 -0500 Matthew Turk wrote: ># cat /usr/vice/cache > /afs:/usr/vice/cache:3575203 ># df -k /usr/vice/cache > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/hda7 3763372 3572204 0 100% /usr/vice/cache 3575203 is not less than 3572204. A good rule of thumb (and the one used by the startup scripts to compute cache size if you ask for it to be set automatically) is to configure the cache size to be no more than 80% of the size of the cache partition. So here, you should use a number like 3010000. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From J.F.Wheeler@rl.ac.uk Mon Mar 29 15:37:34 2004 From: J.F.Wheeler@rl.ac.uk (Wheeler, JF (Jonathan) ) Date: Mon, 29 Mar 2004 16:37:34 +0100 Subject: [OpenAFS] 'no space left on device' while importing Message-ID: <350DC7048372D31197F200902773DF4C02EFBC10@exchange11.rl.ac.uk> > -----Original Message----- > From: Tino Schwarze [mailto:openafs-info.lists@tisc.de] > Sent: 29 March 2004 16:28 > To: openafs-info@openafs.org > Subject: Re: [OpenAFS] 'no space left on device' while importing > > There used to be a magic number of about 90%, so lower it to > 3387000 or so... I don't think that it will make a difference.. You can check your cache size on the fly using: fs getcacheparms and set it using fs setcachesize 3387000 Assuming that this corrects the problem, remember to update /usr/vice/etc/cacheinfo Jonathan Wheeler e-Science Centre Rutherford Appleton Laboratory From rader@ginseng.hep.wisc.edu Mon Mar 29 15:43:01 2004 From: rader@ginseng.hep.wisc.edu (rader@ginseng.hep.wisc.edu) Date: Mon, 29 Mar 2004 09:43:01 -0600 Subject: [OpenAFS] 'no space left on device' while importing In-Reply-To: Message from Tino Schwarze of "Mon, 29 Mar 2004 17:28:13 +0200." <20040329152813.GD28819@easy.in-chemnitz.de> Message-ID: <200403291543.i2TFh1U03513@ginseng.hep.wisc.edu> > On Mon, Mar 29, 2004 at 10:20:16AM -0500, Matthew Turk wrote: > > # cat /usr/vice/cache > > /afs:/usr/vice/cache:3575203 > > # df -k /usr/vice/cache > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/hda7 3763372 3572204 0 100% /usr/vice/cache > > > > But, df -h reports: > > > > Filesystem Size Used Avail Use% Mounted on > > /dev/hda7 3.6G 3.5G 0 100% /usr/vice/cache > > > > Maybe this is too big? Should I just start my cache over? > From: Tino Schwarze > There used to be a magic number of about 90%, so lower it to 3387000 or > so... I don't think that it will make a difference.. i've seen 90% fail--didn't happen often--but it happened. use 85% or less. refer to the thread "no cache size in cacheinfo, 100% of space" ca 31 Oct 2002. steve - - - systems & network guy high energy physics university of wisconsin From rra@stanford.edu Mon Mar 29 18:04:14 2004 From: rra@stanford.edu (Russ Allbery) Date: Mon, 29 Mar 2004 10:04:14 -0800 Subject: [OpenAFS] (no subject) In-Reply-To: <20040329130616.9F8AE725F@sitemail.everyone.net> (Arthur Grotz's message of "Mon, 29 Mar 2004 05:06:16 -0800 (PST)") References: <20040329130616.9F8AE725F@sitemail.everyone.net> Message-ID: <87r7vb5y3l.fsf@windlord.stanford.edu> Arthur Grotz writes: > I have installed openafs on debian 3.0, everything runs great untill I > tried start afsd, i had these errors. >> afsd: All AFS daemons started. >> afsd: Can't mount AFS on /afs(22) > (/afs is already created on disk.) > Debian openafs installation is little different from the others, config > files were installed in different directories and nowhere in the > internet i couldn't found correct documentation, and i have a lot of > troubles to set it up correctly. Does anyone know what these erros > means and how to solve this problem ? How did you get the kernel modules for Debian? Did you build them yourself from openafs-modules-source using make-kpkg, or did you install binary module packages? -- Russ Allbery (rra@stanford.edu) From openafs@butchwax.com Mon Mar 29 07:44:22 2004 From: openafs@butchwax.com (John Morris) Date: 29 Mar 2004 01:44:22 -0600 Subject: [OpenAFS] Fileserver process hung on startup Message-ID: <1080546262.3872.30.camel@capsulecorp> Hi! See what y'all can do with this. Openafs 2.9.11, custom smp kernel 2.4.23. Three fileserver cell, one fileserver, kug, suddenly stops serving files; clients see 'connection timed out'. AFS server processes seem to be running normally as reported by bos status. # bos status kug -long -local Instance ptserver, (type is simple) currently running normally. Process last started at Sun Mar 28 16:51:58 2004 (2 proc starts) Last exit at Sun Mar 28 16:51:55 2004 Command 1 is '/usr/afs/bin/ptserver' Instance vlserver, (type is simple) currently running normally. Process last started at Sun Mar 28 16:51:58 2004 (2 proc starts) Last exit at Sun Mar 28 16:51:55 2004 Command 1 is '/usr/afs/bin/vlserver' Instance fs, (type is fs) currently running normally. Auxiliary status is: file server running. Process last started at Mon Mar 29 01:29:36 2004 (11 proc starts) Last exit at Mon Mar 29 01:29:36 2004 Last error exit at Mon Mar 29 01:29:36 2004, by vol, by exiting with code 1 Command 1 is '/usr/afs/bin/fileserver' Command 2 is '/usr/afs/bin/volserver' Command 3 is '/usr/afs/bin/salvager' # Port 2040 not being listened on: # netstat -tl | grep 2040 # Get these errors from 2040 not being open: FSYNC_clientInit temporary failure (will retry): Connection refused Any fs commands on kug's filesystems hang for a long time before timing out. strace on fileserver process finds process in seemingly hung state, ie. no system calls until process is killed. Haven't noticed anything else funny about /vicepa; salvages complete with no errors. Volume DB is frozen as long as fileserver process is running; once fileserver is killed, voldb comes back online. Lsof shows kug's fileserver process compared with another normally running fileserver's process has similar files open, except localhost:2040, and of course /vicepa files. restarts and reboots don't help. That's all I can think of. Any ideas? Thanks for any suggestions! My home directory is on this fileserver, so help will be appreciated extra! John From shadow@dementia.org Mon Mar 29 20:37:28 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 29 Mar 2004 15:37:28 -0500 (EST) Subject: [OpenAFS] Fileserver process hung on startup In-Reply-To: <1080546262.3872.30.camel@capsulecorp> References: <1080546262.3872.30.camel@capsulecorp> Message-ID: On Mon, 29 Mar 2004, John Morris wrote: > Hi! See what y'all can do with this. > > Openafs 2.9.11, unlikely. > custom smp kernel 2.4.23. setenv LD_ASSUME_KERNEL 2.4.1 in a wrapper around the bosserver. From mturk@astro.psu.edu Mon Mar 29 20:41:21 2004 From: mturk@astro.psu.edu (Matthew Turk) Date: Mon, 29 Mar 2004 15:41:21 -0500 (EST) Subject: [OpenAFS] 'no space left on device' while importing In-Reply-To: <200403291543.i2TFh1U03513@ginseng.hep.wisc.edu> Message-ID: > use 85% or less. Taking everyone's advice, I shut down AFS and reformatted my cache while I resized it. This seems to have fixed it, as I can now move files quite easily. Thanks! mjt From deengert@anl.gov Mon Mar 29 22:52:32 2004 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 29 Mar 2004 16:52:32 -0600 Subject: [OpenAFS] OpenAFS-1.3.62 on Windows with gssklog Message-ID: <4068A8B0.58409D65@anl.gov> For any of you who have been using gssklog, on Windows, I have a version that will work with 1.3.62 If you try this, let me know if it works as expected. It can be found at ftp://achilles.ctd.anl.gov/pub/DEE/gssklog-0.10a-1.3.6200.run.zip I will be releasing new source that matches this in a few days. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From shadow@dementia.org Mon Mar 29 23:08:50 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 29 Mar 2004 18:08:50 -0500 (EST) Subject: [OpenAFS] Fileserver process hung on startup In-Reply-To: <1080594425.4771.31.camel@capsulecorp> References: <1080546262.3872.30.camel@capsulecorp> <1080594425.4771.31.camel@capsulecorp> Message-ID: On Mon, 29 Mar 2004, John Morris wrote: > Oops, 1.2.11. :) > > I tried this, but no effect, the fileserver is still not listening on > 2040. What should this have changed? is the loopback interface up? ifconfig lo From shadow@dementia.org Tue Mar 30 03:30:06 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 29 Mar 2004 22:30:06 -0500 (EST) Subject: [OpenAFS] Fileserver process hung on startup In-Reply-To: <1080614467.4771.41.camel@capsulecorp> References: <1080546262.3872.30.camel@capsulecorp> <1080594425.4771.31.camel@capsulecorp> <1080614467.4771.41.camel@capsulecorp> Message-ID: On Mon, 29 Mar 2004, John Morris wrote: > What I'm guessing is that, judging by the fileserver's complete > unresponsiveness and that it's not even making system calls, that > something is hanging up, maybe a system call? Is there any > documentation on the '-d #' argument to the fileserver executable's > commandline? What debug level could I give it so it would give me a > clue what it's doing? Where else can I look for debugging information > besides the sources I listed in my first email (included below for a > reminder)? it won't really help. the debug messages probably won't give you a hint where it's hanging. attach before it hangs; better yet wrap fileserver itself with a shell script which straces to a file. I really like the LD_ASSUME_KERNEL idea; ps auxwwe |grep fileserver|grep -v grep and see if the LD_ASSUME_KERNEL variable is in the fileserver's environment. From shadow@dementia.org Tue Mar 30 06:38:04 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Tue, 30 Mar 2004 01:38:04 -0500 (EST) Subject: [OpenAFS] Fileserver process hung on startup In-Reply-To: <1080628452.4080.75.camel@capsulecorp> References: <1080546262.3872.30.camel@capsulecorp> <1080594425.4771.31.camel@capsulecorp> <1080614467.4771.41.camel@capsulecorp> <1080628452.4080.75.camel@capsulecorp> Message-ID: On Tue, 30 Mar 2004, John Morris wrote: > Cool, got the strace. After the expected loading of .so files and > config files and such, we see it contact the vldbs of the other two > servers and do a 'rt_sigsuspend'; the second from which it never > returns. Is this a thread locking issue? maybe, but if so the LD_ASSUME_KERNEL should have fixed it, unless someone broke that, and one would hope if they did that they'd also have fixed pthreads. From openafs@butchwax.com Mon Mar 29 21:07:05 2004 From: openafs@butchwax.com (John Morris) Date: 29 Mar 2004 15:07:05 -0600 Subject: [OpenAFS] Fileserver process hung on startup In-Reply-To: References: <1080546262.3872.30.camel@capsulecorp> Message-ID: <1080594425.4771.31.camel@capsulecorp> Oops, 1.2.11. :) I tried this, but no effect, the fileserver is still not listening on 2040. What should this have changed? Thanks for the suggestion! John On Mon, 2004-03-29 at 14:37, Derrick J Brashear wrote: > On Mon, 29 Mar 2004, John Morris wrote: > > > Hi! See what y'all can do with this. > > > > Openafs 2.9.11, > > unlikely. > > > custom smp kernel 2.4.23. > > setenv LD_ASSUME_KERNEL 2.4.1 in a wrapper around the bosserver. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From openafs@butchwax.com Tue Mar 30 02:41:07 2004 From: openafs@butchwax.com (John Morris) Date: 29 Mar 2004 20:41:07 -0600 Subject: [OpenAFS] Fileserver process hung on startup In-Reply-To: References: <1080546262.3872.30.camel@capsulecorp> <1080594425.4771.31.camel@capsulecorp> Message-ID: <1080614467.4771.41.camel@capsulecorp> # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.099 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% loss, time 0ms rtt min/avg/max/mdev = 0.099/0.099/0.099/0.000 ms # ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:109901 errors:0 dropped:0 overruns:0 frame:0 TX packets:109901 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:10104040 (9.6 Mb) TX bytes:10104040 (9.6 Mb) # Sure is. What I'm guessing is that, judging by the fileserver's complete unresponsiveness and that it's not even making system calls, that something is hanging up, maybe a system call? Is there any documentation on the '-d #' argument to the fileserver executable's commandline? What debug level could I give it so it would give me a clue what it's doing? Where else can I look for debugging information besides the sources I listed in my first email (included below for a reminder)? Thanks again! John On Mon, 2004-03-29 at 17:08, Derrick J Brashear wrote: > On Mon, 29 Mar 2004, John Morris wrote: > > > Oops, 1.2.11. :) > > > > I tried this, but no effect, the fileserver is still not listening on > > 2040. What should this have changed? > > is the loopback interface up? > > ifconfig lo > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info Hi! See what y'all can do with this. Openafs 2.9.11, custom smp kernel 2.4.23. Three fileserver cell, one fileserver, kug, suddenly stops serving files; clients see 'connection timed out'. AFS server processes seem to be running normally as reported by bos status. # bos status kug -long -local Instance ptserver, (type is simple) currently running normally. Process last started at Sun Mar 28 16:51:58 2004 (2 proc starts) Last exit at Sun Mar 28 16:51:55 2004 Command 1 is '/usr/afs/bin/ptserver' Instance vlserver, (type is simple) currently running normally. Process last started at Sun Mar 28 16:51:58 2004 (2 proc starts) Last exit at Sun Mar 28 16:51:55 2004 Command 1 is '/usr/afs/bin/vlserver' Instance fs, (type is fs) currently running normally. Auxiliary status is: file server running. Process last started at Mon Mar 29 01:29:36 2004 (11 proc starts) Last exit at Mon Mar 29 01:29:36 2004 Last error exit at Mon Mar 29 01:29:36 2004, by vol, by exiting with code 1 Command 1 is '/usr/afs/bin/fileserver' Command 2 is '/usr/afs/bin/volserver' Command 3 is '/usr/afs/bin/salvager' # Port 2040 not being listened on: # netstat -tl | grep 2040 # Get these errors from 2040 not being open: FSYNC_clientInit temporary failure (will retry): Connection refused Any fs commands on kug's filesystems hang for a long time before timing out. strace on fileserver process finds process in seemingly hung state, ie. no system calls until process is killed. Haven't noticed anything else funny about /vicepa; salvages complete with no errors. Volume DB is frozen as long as fileserver process is running; once fileserver is killed, voldb comes back online. Lsof shows kug's fileserver process compared with another normally running fileserver's process has similar files open, except localhost:2040, and of course /vicepa files. restarts and reboots don't help. That's all I can think of. Any ideas? Thanks for any suggestions! My home directory is on this fileserver, so help will be appreciated extra! John From openafs@butchwax.com Tue Mar 30 06:34:12 2004 From: openafs@butchwax.com (John Morris) Date: 30 Mar 2004 00:34:12 -0600 Subject: [OpenAFS] Fileserver process hung on startup In-Reply-To: References: <1080546262.3872.30.camel@capsulecorp> <1080594425.4771.31.camel@capsulecorp> <1080614467.4771.41.camel@capsulecorp> Message-ID: <1080628452.4080.75.camel@capsulecorp> Cool, got the strace. After the expected loading of .so files and config files and such, we see it contact the vldbs of the other two servers and do a 'rt_sigsuspend'; the second from which it never returns. Is this a thread locking issue? If it's relevant, this is openafs 1.2.11 built from a nearly-stock SRPM on this machine, which runs RH8 with custom kernel and stock RH glibc 2.2.93. Sorry for the line-wrapping, I'm not in my preferred environment right now.... sendmsg(7, {msg_name(16)={sin_family=AF_INET, sin_port=htons(7003), sin_addr=inet_addr("67.67.198.201")}},\ msg_iov(2)=[{"\257\356\r\2001\177\254\274\0\0\0\1\0\0\0\1\0\0\0\1\1\5"..., 28}, {"\0\0\2\24\0kK\356\0\0\3\34\241\0\0\37&\377\377\377\276\0"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 92 time(NULL) = 1080626914 kill(5685, SIGRTMIN) = 0 kill(5685, SIGRTMIN) = 0 time(NULL) = 1080626914 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 rt_sigsuspend([] --- SIGRTMIN (Real-time signal 0) --- <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) sigreturn() = ? (mask now [RTMIN]) gettimeofday({1080626914, 364860}, NULL) = 0 gettimeofday({1080626914, 365028}, NULL) = 0 time(NULL) = 1080626914 gettimeofday({1080626914, 365310}, NULL) = 0 gettimeofday({1080626914, 365488}, NULL) = 0 sendmsg(7, {msg_name(16)={sin_family=AF_INET, sin_port=htons(7003), sin_addr=inet_addr("66.227.12.105")}},\ msg_iov(2)=[{"\257\356\r\2001\177\254\270\0\0\0\1\0\0\0\1\0\0\0\1\1\5"..., 28}, {"\0\0\2\24\0kK\356\0\0\3\34\241\0\0\37&\377\377\377\276\0"..., 64}], msg_controllen=0, msg_flags=0}, 0) = 92 time(NULL) = 1080626914 time(NULL) = 1080626914 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 rt_sigsuspend([] As for the environment, the env variable is in there: root 5681 0.0 0.6 17324 3544 ? S< 00:08 0:00 /usr/afs/bin/fileserver HOSTNAME=kugioga.butchwax.com TERM=dumb SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=192.168.3.101 48003 22 SSH_TTY=/dev/pts/2 EMACS=t USER=root LS_COLORS= TERMCAP= USERNAME=root COLUMNS=80 PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin MAIL=/var/spool/mail/root LC_COLLATE=C PWD=/usr/afs/logs INPUTRC=/etc/inputrc LANG=en_US SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass HOME=/root SHLVL=3 LD_ASSUME_KERNEL=2.4.1 BASH_ENV=/root/.bashrc LOGNAME=root LESSOPEN=|/usr/bin/lesspipe.sh %s DISPLAY=localhost:10.0 G_BROKEN_FILENAMES=1 _=/usr/bin/strace Thanks! Think we're getting closer? John On Mon, 2004-03-29 at 21:30, Derrick J Brashear wrote: > On Mon, 29 Mar 2004, John Morris wrote: > > > What I'm guessing is that, judging by the fileserver's complete > > unresponsiveness and that it's not even making system calls, that > > something is hanging up, maybe a system call? Is there any > > documentation on the '-d #' argument to the fileserver executable's > > commandline? What debug level could I give it so it would give me a > > clue what it's doing? Where else can I look for debugging information > > besides the sources I listed in my first email (included below for a > > reminder)? > > it won't really help. the debug messages probably won't give you a hint > where it's hanging. > > attach before it hangs; better yet wrap fileserver itself with a shell > script which straces to a file. > > I really like the LD_ASSUME_KERNEL idea; ps auxwwe |grep fileserver|grep > -v grep > and see if the LD_ASSUME_KERNEL variable is in the fileserver's > environment. > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From vervoom@hotmail.com Tue Mar 30 14:17:06 2004 From: vervoom@hotmail.com (J S) Date: Tue, 30 Mar 2004 14:17:06 +0000 Subject: [OpenAFS] ftp overrides AFS permissions Message-ID: Hi, I have noticed that when I ftp to a host with an AFS client as my normal userid, I can cd/del/put into AFS directories where I don't have permissions. I can do this eventhough I haven't logged on to AFS. The root userid on this box has administrator priviledges on AFS but I'm ftp'ing with my own userid. Does anyone get this? Thanks for any help. Ed. _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband From wingc@engin.umich.edu Tue Mar 30 14:54:02 2004 From: wingc@engin.umich.edu (Christopher Allen Wing) Date: Tue, 30 Mar 2004 09:54:02 -0500 (EST) Subject: [OpenAFS] ftp overrides AFS permissions In-Reply-To: Message-ID: Sure, the usual cause of this problem is that you logged in as root, obtained a PAG and an administrator token, and then started the FTP server. In this case the FTP server will inherit the PAG and tokens. The solution is to never start a daemon process as root if you have AFS tokens. Here is a program that when run as root will remove the current PAG: http://www-personal.engin.umich.edu/~wingc/code/unpagsh.c When restarting a daemon process, what I usually do first is: 1. Become root 2. Run 'unpagsh' to drop any PAG 3. Run 'tokens' to make sure that the default PAG for root does not have tokens -Chris Wing wingc@engin.umich.edu On Tue, 30 Mar 2004, J S wrote: > Hi, > > I have noticed that when I ftp to a host with an AFS client as my normal > userid, I can cd/del/put into AFS directories where I don't have > permissions. I can do this eventhough I haven't logged on to AFS. The root > userid on this box has administrator priviledges on AFS but I'm ftp'ing with > my own userid. > > Does anyone get this? > > Thanks for any help. > > Ed. From dhk@ccre.com Tue Mar 30 15:03:51 2004 From: dhk@ccre.com (Dexter 'Kim' Kimball) Date: Tue, 30 Mar 2004 08:03:51 -0700 Subject: [OpenAFS] Newbie Question In-Reply-To: Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C4162D.89B3AE10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The "make dest" will create a tree from which you can copy the files referred to in the QuickStart instructions at the URL below. By default it creates a directory just below the top directory. The directory will look something like "linux_2.x_i386 ..." QuickStart will instruct you to copy some files from CD. Instead of CD, you'll copy them from the "linux_2.x_...." directory. The fileserver partition can be called /'vicep? where ? equals any character. /vicepa is a good place to start IMO. Name doesn't make any difference but must be a partition, not a directory. (can also use /vicep?? up to ?? = mn ... I could be wrong about the mn) /usr/vice/cache is used by the cache manager (AFS client) to cache data/files it retrieves from AFS servers. It doesn't _have_ to be on its own partition, but is much easier to manage if it is. If you've got enough RAM you can cache to memory instead. I recommend cacheing to disk, even if the partition you cache to is just 100 MB or so. Memory cache has a history of causing instability on some platforms, so, IMO, I wouldn't use it until the machine's up and running and you're sure there are no other problems. I use mem cache with OpenAFS 1.2.11 and RH9 without issues, but have had problems in the past and am not sure of Fedora. Others on the list may be able to better advise. So, if you haven't, go ahead and "make dest" and look for the resulting directory. Kim > -----Original Message----- > From: Dexter 'Kim' Kimball [mailto:dhk@ccre.com] > Sent: Tuesday, March 30, 2004 6:28 AM > To: marena23@hotmail.com > Subject: Re: [OpenAFS] Newbie Question > > Hi Mike, > > http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#HDRWQ18 will > give you the instructions for installing the first AFS server > > You'll need to create at least two partitions > > A "vice partition" for the fileserver and a cache partition for the AFS > client. > > As a further piece of detective work, what do you see when you > > $ ls /usr/sbin/vos > > Also, try "make dest" > > Did you try using the RPMs for RH9? > > Kim > > > > On 3/29/2004 6:13:02 PM, Mike Arena (marena23@hotmail.com) wrote: > > Kim, > > I guess that's my problem, I have nothing in those folders. I don't know > > where I went wrong. I unpacked > > openafs-1.2.11-src.tar into /root then ran ./configure, then make, and > > finally make install. How do I create my cell and get this going from > this > > > > point? The output of my df command is: > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/hda2 5842664 2899216 2646648 53% / > > /dev/hda1 101086 6348 89519 7% /boot > > none 62960 0 62960 0% /dev/shm > > > > I also have nothing in /usr/afs/local/BosConfig. Sorry if this seems > like > > > > too basic of a question for you. I reread everything over and over to > see > > > > what I missed I just can't figure out how to get from where I am not to > > actually creating my cell and serving up content. > > > > Any help or documentation you could give is greatly appreciated, > > thanks, > > Mike > ------=_NextPart_000_0006_01C4162D.89B3AE10 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjMPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHAwAeAAgAAwAAAAIACQEB A5AGAGgNAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAeAAAAUmU6IFtPcGVuQUZTXSBOZXdiaWUgUXVlc3Rpb24AAAACAXEAAQAAABsA AAABxBZZXBujCwVMQqVDm5+JRtiZBNqtAACKg0AAAgEdDAEAAAASAAAAU01UUDpESEtAQ0NSRS5D T00AAAALAAEOAAAAAEAABg4AqoEXaBbEAQIBCg4BAAAAGAAAAAAAAADAA49wsPriT4exrWuVIdC/ woAAAAsAHw4BAAAAAgEJEAEAAAAKCQAABgkAAKwOAABMWkZ1ScTOvAMACgByY3BnMTI1FjIA+Atg bg4QMDMzTwH3AqQD4wIAY2gKwHPwZXQwIAcTAoMAUBBmGHBycQ5QENhUYWibA3ECgH0KgAjIIDsJ by0OMDUCgAqBdgiQd2tpC4BkNAxgYwBQCwNjhxICC8QTkGhlICIAwIZrGLABAHN0IiAD8EZsAyAF AGVhdBiwYbQgdAnRIANSGYBoDeB4aCB5CGAZ0AORBaBwdnkaYBihZgMQB5EJcGZnBJAJcRpgbyAL gBwzUfJ1DeBrUwGQACAdkRlQ8nIXQHRpAiAEIBoQHDNAVVJMIGJlCQB3bi4KogqECoBCHCABAWF8 dWweoQVAGeQfcRkgac8JcB8gBbAcIGp1GVAgNMscMx1wcCLYLiAYgyLowxmTCQBvayBzA3ARMFcb IA8gJpBpGQEiJ5BuIHV4XzIuKDBpM9A4NiAuKOAiIKoeGf8Zkx7GG2MdcRvzJvIcdRrDdENEJUFJ HtEaAB1Qb+pmLSEsG2InGbIcBRrw/xrDHEIn6SjhKQAkqSCqGJLrHIMEkHYEkCAKsR8wHzKfG6Mg QBuhGbAdQS8nFqDwY2VwPxsBBJAYsDVg2GVxdQdAH3FuHCAQ4usA0BogciVBLzUTGlAEAP0aQWcm sB1QC1E1MB1iGVCRHoJJTU8lQU5hLFHkZG8HkG4nBUAY4zZylyLgASA1oW44wWJ1OpHPI5QaQTN3 LlBubwVAIsn9JUEoG7I2MR2AI5AYsDd0uj81YHUkkB1xP+E9OqB/A6Ao4S1wG+Eh0B1QNFF3vwNg J2EBoAhgH6RAwCkgquovI5ByN3MvG7AQ4BiwPzfxP0FBkRwkRHQDgWFn0TNBKEFGBfBjJ5AJ8Cx0 KSujRINkGhBhL/8chCIRCXAacAiQMzAsxUay3TMEcy1SBUA6Nl8Q8DMw/l8dYjRRM+EiEAQgIHAD oP882TvyN/E8MBtBGgAAkDNBfx1xRiQdkC4QIhEEACCbSX8uEC5yMzA4MQVACfAIYGfxG1BSQU0b aESDTsIvUL8jQh7CLcEtUhzRBaBtB4CfFwBFtCdSHXEi4HNrLlD/STFMQS4QHEIzeBt0UuU38ecj gw9AEVBNQi3wBcAm8P0lQU1TZER0EPAiohsgGVD/I0IuARuwI5AnUh7CAaADEH8iEFtxA6AsMwtR ADAFsG3+cy5QJvAuUDmBXlEZgEFi9zpyP0IiEXUCMAMRQqNEgfkLgGUnROEkkABwHVAfAL5uAwBC ElTxLnI1sXMIcP8kUTWTCsAYsD2ALfBjEjNg/wNgAmAvUEpzPzNTUUW1A/AxHEAgT3AJ8EayMS6J KFAxMWFDUkg5ZeP/QmIEAQpQXgE78ktyWqE4cf9kVR2WCrAjoWFSOfA9c2LDrS4BRgmABbBhJUFP YxL/TIEdtCeQI6EAwBwgPIJkcX9LxAJAM0Et0BagESAgm1P/XkFPYRtyS3I6cS5QOEAaQP8YoC3R YVIY2mFSJqNdwRwzvwlwYsAh4CdSMS8gs0sHcM8gqiCoCzAnkDM2AUAX0N8BQGRBGiAfIAvSNCVQ d9BXDxN5IBH0MSjALXqCT/0FEGcLgAdAWdEEEEZReoMfIKZ4lHhhCxN4lmktMcw0NAFAJ5AxOFkA DMFtfiNia/ADYToDMAySYlERUERleG7iJ3YxJ8ogdjFiNJEgWwDAAxCBHXA6ZGhrQGMZ4fouVKFd CuMKgX9QBmACMFo6f9ZUaGFIAHkuUE2zCsAbQTMwLlAB0DB5MFA2OjI4EWBNgwdUD4IAf9YAwDuR YTIzQB0TwHSBsoKigwh1YmrTIxGD11Jlf7BbZkWC4P8HwVyQHfIZQR9Bdmx8r3jCZ3fkDwYYB0hp BdAnoSwFIKpoAkBwOi8vdz2RgC4cAIfBA9CRsHJnJi8KsEZgcy86MGMvJR4YVQMAeC8hwHFiEmdZ ADUukRBtI0jwRFJXUX6QJVAZk3sA/1EhK3NEoh7ac7JcQxmwVXPfHFMREAVASdggqlkuhGDQ3x1E GeYFQBygapJ0XuAzaPsQsCC5QRjANRIzaBlwc7Z/Mslq00W1M3hztka4IJtB/SKiZghwY/QIkDjB LgEBAPd4spXSXuByVhEbEB+ROjC/G2MRIEHBGKBXhCCqJCaQqwQgQ9NzXJBuN3BvnRw/PwEuUBpw HCAY2SCqRGmPYjOqc1vkHEJSUE2XRF1ncT91f3aPILNPA6AzGC8yObEQhaQxMzr9ecAgraCE0Sei BxCHwT6Qf4efVKFHUEHhGiCD0CCzPu+BEpBFtUBBMGdoYQQgHED7GhBg8W0cIGRFXqJo8z2B/ydD HaOpQBqhBvAEgUpxQTDrOjA6cms9gHe05jWEXsH/RyFB1EESX+AKsB5ACYC05peRxX4QZtMtQ/Bj Lh5x+x2RHXEvA2A9kRxBA6A24P9A0URgAiAcgLZACXCqYacCvxjiLlBhUbTmHIB7IWwcIPcY45el JUBIJAGmQUExGfT/txE1MBmxYVJGYB+iN/E4QF8nUi+FBAC05rTmcMYhdHc1YBiSQmFwPAEuAbcR ZF9boVSxYVIEALTXRhySecctoRrwy4gxSy0CYJLwlmsEIMuDVUUSQXaBwftuM80hJQXQCGACMB1B jBbntUCS0EkwL2hIALIA0BvANTg0MjY2eTGFgPA4OTkyelHRcdFA0THplUE1M85AL88OZxDQHM8P QA9AKLHLgzYz0oLLgdnRoDUxZ5AlUDfS4Qbg/z2QtOY9gGDQ1C3VdbEgeBA3y4fZtNl2MNLhz5Jz aH+vRcdoQTA+87f+Q9OSAS/zzHEHQC9CqUAIUMByJUD/cFAdIFOhVqI38aaxaeEnku/HDh1wS+FO YWMt8hpQNhD/i9RzoxtxQRIJcBnxHVBJMfsjUCc0b6AG5cM48gngxw77pfNBMG0EAR1BQTAjgxux /zqBwITIolqgJAIdgMWCGsX/u0RrFR1wtOY28TYhwrEZ4/8nUsTKMwInUkARwFEaIKKn7cdoQTaB GKBsJJAFsZLh/nVU0QGQV1hBY5XDxeIZ8vnCsWFwErAFkAcwzqG1l322oW7MoLWXkAIgqhQhAAH3 sAAAHgBCEAEAAAAsAAAAPE9DRVBJSExCR05HSUJLRkJHQUVGRUVDQUNJQUEuZGhrQGNjcmUuY29t PgALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAAAABGAAAA ABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAACdqAQAeAAmACCAGAAAAAADAAAAA AAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAAB AAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAAyACCAGAAAA AADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUA AAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAAAABG AAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFKACCAGAAAAAADA AAAAAAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4DwEA AAAQAAAAwAOPcLD64k+Hsa1rlSHQvwIB+g8BAAAAEAAAAMADj3Cw+uJPh7Gta5Uh0L8CAfsPAQAA AE4AAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA3 2W4AAABEOlxFTUFJTFxvdXRsb29rLnBzdAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAACwAAAA8 T0NFUElITEJHTkdJQktGQkdBRUZBRUNCQ0lBQS5kaGtAY2NyZS5jb20+AAMABhC6y7N/AwAHEAgJ AAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAAVEhFIk1BS0VERVNUIldJTExDUkVBVEVBVFJF RUZST01XSElDSFlPVUNBTkNPUFlUSEVGSUxFU1JFRkVSUkVEVE9JTlRIRVFVSUNLU1RBUlRJTlNU UlVDVElPTlNBVFRIRVVSTAAAAACI+w== ------=_NextPart_000_0006_01C4162D.89B3AE10-- From dhk@ccre.com Tue Mar 30 15:12:43 2004 From: dhk@ccre.com (Dexter 'Kim' Kimball) Date: Tue, 30 Mar 2004 08:12:43 -0700 Subject: [OpenAFS] Newbie Question In-Reply-To: Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C4162E.C6FC0B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mike, I misspoke -- the name of the fileserver partition mount point does make a difference -- the first part of the mount point must be /vicep -- the fileserver doesn't look for names other than /vicep?? Kim > -----Original Message----- > From: Dexter 'Kim' Kimball [mailto:dhk@ccre.com] > Sent: Tuesday, March 30, 2004 8:04 AM > To: marena23@hotmail.com > Cc: Openafs-Info@Openafs.Org > Subject: RE: Re: [OpenAFS] Newbie Question > > The "make dest" will create a tree from which you can copy the files > referred to in the QuickStart instructions at the URL below. > > By default it creates a directory just below the top directory. The > directory will look something like "linux_2.x_i386 ..." > > QuickStart will instruct you to copy some files from CD. Instead of CD, > you'll copy them from the "linux_2.x_...." directory. > > The fileserver partition can be called /'vicep? where ? equals any > character. /vicepa is a good place to start IMO. Name doesn't make any > difference but must be a partition, not a directory. (can also use > /vicep?? up to ?? = mn ... I could be wrong about the mn) > > /usr/vice/cache is used by the cache manager (AFS client) to cache > data/files it retrieves from AFS servers. It doesn't _have_ to be on its > own partition, but is much easier to manage if it is. > > If you've got enough RAM you can cache to memory instead. I recommend > cacheing to disk, even if the partition you cache to is just 100 MB or so. > Memory cache has a history of causing instability on some platforms, so, > IMO, I wouldn't use it until the machine's up and running and you're sure > there are no other problems. I use mem cache with OpenAFS 1.2.11 and RH9 > without issues, but have had problems in the past and am not sure of > Fedora. Others on the list may be able to better advise. > > So, if you haven't, go ahead and "make dest" and look for the resulting > directory. > > Kim > > > -----Original Message----- > From: Dexter 'Kim' Kimball [mailto:dhk@ccre.com] > Sent: Tuesday, March 30, 2004 6:28 AM > To: marena23@hotmail.com > Subject: Re: [OpenAFS] Newbie Question > > Hi Mike, > > http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#HDRWQ18 > will give you the instructions for installing the first AFS server > > You'll need to create at least two partitions > > A "vice partition" for the fileserver and a cache partition for the > AFS client. > > As a further piece of detective work, what do you see when you > > $ ls /usr/sbin/vos > > Also, try "make dest" > > Did you try using the RPMs for RH9? > > Kim > > > > On 3/29/2004 6:13:02 PM, Mike Arena (marena23@hotmail.com) wrote: > > Kim, > > I guess that's my problem, I have nothing in those folders. I > don't know > > where I went wrong. I unpacked > > openafs-1.2.11-src.tar into /root then ran ./configure, then make, > and > > finally make install. How do I create my cell and get this going > from this > > > > point? The output of my df command is: > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/hda2 5842664 2899216 2646648 53% / > > /dev/hda1 101086 6348 89519 7% /boot > > none 62960 0 62960 0% /dev/shm > > > > I also have nothing in /usr/afs/local/BosConfig. Sorry if this > seems like > > > > too basic of a question for you. I reread everything over and over > to see > > > > what I missed I just can't figure out how to get from where I am > not to > > actually creating my cell and serving up content. > > > > Any help or documentation you could give is greatly appreciated, > > thanks, > > Mike > ------=_NextPart_000_000B_01C4162E.C6FC0B90 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IisPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHAwAeAAgADAAAAAIAEgEB A5AGABgOAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAeAAAAUmU6IFtPcGVuQUZTXSBOZXdiaWUgUXVlc3Rpb24AAAACAXEAAQAAACAA AAABxBZZXBujCwVMQqVDm5+JRtiZBNqtAACKg0AAA2onkAIBHQwBAAAAEgAAAFNNVFA6REhLQEND UkUuQ09NAAAACwABDgAAAABAAAYOACBfWWkWxAECAQoOAQAAABgAAAAAAAAAwAOPcLD64k+Hsa1r lSHQv8KAAAALAB8OAQAAAAIBCRABAAAAtQkAALEJAABbEQAATFpGdfdLNMQDAAoAcmNwZzEyNRYy APgLYG4OEDAzM08B9wKkA+MCAGNoCsBz8GV0MCAHEwKDAFAQZhhwcnEOUBDYVGFomwNxAoB9CoAI yCA7CW8tDjA1AoAKgXYIkHdraQuAZDQMYGMAUAsDYw8SAgvFCrEKgE1pa2UgLCBJIG0EAXBvgRkA IC0tIHRoGdBEbmEHgCBvZhoTZlcDEAeQBJB2BJAgCrF0fmkcAAIgGVAIYAIwG8BvcwuABUBkbweR AMAZwWHbHSAGkGYEkAnwYxnXGyCfERAcsRvhGqYcem11H0GaYhnQLxagHnBwIB6Y8xtHHTJuJwVA CQAZsBsQ9wWxGmIEIG8aIQXAGiADkdkhdD8/GIQYhEsHcCW64Qr0bGkzNgFAF9AYcdUDYHQFkHQL 0jQh0CewZw8TKQAR9DE2GeEqYU89BRBnC4AHQAXQB5BzYfxnZSpjJbYodBhzCzEodmBpLTE0NAFA J8AxHDgwAUAM0C4DYiBGLQNhOgMwDJJiEVBEZZZ4KJAFwCcmcScgJnE2YgdAAyBbAMADEHRvQDpk aGtAYwUAZfIuBaBtXQrjCoEvMAZgFQIwOi+2VApQc2RhGnkZIE0KwBDgIDMwSxkgAdAwKRA4OjWR QXpNMudUMeAvtgDAHkFh6DIzQBPAdDGSMoIy52RDYzO3T3A3oQPQLVRJbgIQQDn1LiqwZzEy6HVi aiihM7dSRSkvkFJlL5BbOfJBRpZTMsAHwWIIkCBRNFH/HCImrCyPKKInxgBQDwYLpjsTkBoxIh2D AQAfQCIgtwPwMVEyUWEokB3BdAnRtxsQA2FD4GgN4DUQeQhgp0QwA5EFoHB5GtggCXDnHiEJcRoQ byALgBoTPpB5DeBrUwGQH5ELgB9Ach8XQBwiBCBEcBoTVVJM0yExCQB3LiW6QkaAAQH8YXUxwEfw BUBEREnRHeHvCXAosAWwRoBqIQRKwRoT9zHQIcBNRy4h0ELyTUhD8/0jk3MDcBEwRYAPICOAGPED QyAnwG51eF8yLqtSkCfQOCpALlNAIiW6/0h5Q/NJJkXDR9FGU1FSRtX5RSNDRE+hOnAfQERgR7Dv GrFXkBkgRdEnRBJGZUVQ/0UjGiJSSVNBU2BPCSW6QvJ/Gy8cMkYSIUFGEDFQR6EvLiclREVhHjEg X8BlcfZ1B0BJ0W5GgBDiANAwYd9PoSF0HdAEAB3BZyOgR7AfC1EecUfRH0AfgklNT31PoU4aciMW HYRg4R35Yt51INgd0BvXGSBuJIBNGv1PoShGEmCRR+AhACFWJZDvaZAhwEfRakE9GVADoFNB3xkx BaBMMEewIUF3A2BRwa8BoAhgSgRrICklui8hAPpyIXMvRhAQ4BnQYlFpob9r8UaEbtQDgSuBBcAo PdH3RDAnwDOBKVYDbuM0gAGQ/i9G5ExxCXBE0AiQG5BXJb9xEl1kOyBXwR0UI1JfEPB9G5BfR8Ih QRxBHBAkYXf/A6BnOWZSYlEg8DUBRGAAkP8kskfgcIRH8BrATHEEAEr7/kkawFjSG5BikQVACfAI YPpnNRBSNhBFyG7jeSJZsP9NokkiWCFXskcxMpEHgBcAz3AUUbJH0R3wc2sZIHOR/3ahGsQb2EXU fUViUU3jD0D5EVBNQhqgBcBRUE+hK0D/fdNu1BDwTQJFgB9ATaIasf9GECEAUbJJIgGgAxAcEIXR nwOgVpMLUQAwBbBtcxkg71FQGSFj8Bkid2vCI1Jpoj9McRyRAxEf827hC4BlJ99vQSHAAHBHsElg bgMAbHL3f1FY0mARcwhwTrFf8zeB/2fRJHUoYQJgWbB002mTfbGfcBUD8BogOeNxEjEuUrDEMTGL o1JIOZBDbML/BAE0UXfUddKFAWLRjrVH9n8KsB9Bi7IacGfTjSMasUbrCYAFsGFPoU8kkiRhSBT/ J8AfQQDARoBm4o7RdiQCQN8boVgwFqARIEr7U4ihecH/RdJ10iNRGSBioB3AGjBYMf+LskM6i7Ij lxoiCXCNIDHA/1GyW48mLz9PQF8BwSgTKO/fKf8rD6GfLS8uMjKlQC6vPy+/MM8x3zLvM/81CjY6 /DI4Ng83HzgvO/89Tz5fz6F/oo8uMUH+SGkF0BjyBZ/aaAJAcDovL3edvHAuRmA65AWwZy8KsEmm oHMvHTBjL0h4VYkDAHgvTCBxYmcukAQ1LrwAbSNIRFL8V1EucCHQQ/Ol8HuBVdP/bwJJOiPihqOs YH/THud0OP2f2llY5IswR6RERiNxeLHfSgGJQBvIELCf6UFDICGC/xvIQ9CeFl0plTNwFRvYnhbr cRhK+0FNAmYIcI5UCJC/HnEasQEAKJLAwolAcoBx/0VwSfEdMEXDESBsIRowgeRdn9okI4AEIG4z c7Zgbv0hcG/IDGlhGSBE0EaAQzl5n9pEaYyT1WOGRBoiUnxQTcI0kdElr6DfGIRPYQOgMy8yOdwA sJQx8jM10DIg2JCvwVICBxD/srFo8LKPraFxsGxBKJCuwL0Ykz6sArs14DAZQGevYesEICThdItR bUaAjqUZIv+TU2fhUaNIA9QwXQEG8ASBr3TRGUAdMCNSa2fgd9/W/1/kiSGukWw0a3IckAqwSKBf CYDf1ry1LfCRMy1uUGPuLkjRR/FH0S8DYGfxGiH/A6BhQGsxbsACIF0g4TAJcP/VUdHyHYIZIIux 39ZdIKYR3mxGgB2DwpVPoEhOYdEx/2uRRFTiAR5wrGGLsqagSgL/YlFioFGyWeUEAN/W39Yc03df wELybMFwZmEaseIBZF+GAX8Ri7IEAN/HRl0yecdYAUVQ9ngxSy0CYL3glmsEIPZzVW9yQXassfuY k/gRJQXQHIJHobcG4DBzvcBzkC9or5Dc8PsLNWA4NDI2NqQhNWA4fDk5qYH8Uvww/CHAMTX6M/kw L/n+kXD7DA9AD0BzUxH2czYz/XL2cfyQNfYxkfAh0Df90QbgJIDf1v9n4Isw/x0AZdwQJ/D2dwSk zQRmMP3R+oJzaNo18ljfGUBpU+LubjM6MS/3YaxQ9C9C1DBD61NPoJqwR4D/fgEawmJR0aGUQVHy 8f6s4Pt2QXjBYxqiHdBgcLbEI9P/0jFrchUgRFFHsHORTbBRlP5vyvYQs2NSFZDx/tDjGUT/R6EZ QE3jRhEjYet085KFAP9OYkfg8HJFJeY0lXWs4N/W/2FRYIHtoURDUbLvul1iUbLfanHrQUSAzZfy WEFg4fNw7mwhwNjhvdF1fzGq0IG4n2vDwLPw0kRS7aFhcOIw9bgwaURxZOCHJOL3kOCHK7ry2Vp9 J0AAIqAAAAAeAEIQAQAAACwAAAA8T0NFUElITEJHTkdJQktGQkdBRUZBRUNCQ0lBQS5kaGtAY2Ny ZS5jb20+AAsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAA AEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAABShQAAJ2oBAB4ACYAIIAYAAAAA AMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA2hQAA AQAAAAEAAAAAAAAAHgALgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADIAI IAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAA2ACCAGAAAAAADAAAAAAAAARgAA AACChQAAAQAAAAsAOoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA8gAggBgAAAAAAwAAA AAAAAEYAAAAAEYUAAAAAAAADAD2ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAUoAIIAYA AAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwBTgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAAC AfgPAQAAABAAAADAA49wsPriT4exrWuVIdC/AgH6DwEAAAAQAAAAwAOPcLD64k+Hsa1rlSHQvwIB +w8BAAAATgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB+b+4 AQCqADfZbgAAAEQ6XEVNQUlMXG91dGxvb2sucHN0AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAA LAAAADxPQ0VQSUhMQkdOR0lCS0ZCR0FFRk9FQ0NDSUFBLmRoa0BjY3JlLmNvbT4AAwAGEEaxdNwD AAcQZAoAAAMAEBAAAAAAAwAREAEAAAAeAAgQAQAAAGUAAABNSUtFLElNSVNTUE9LRS0tVEhFTkFN RU9GVEhFRklMRVNFUlZFUlBBUlRJVElPTk1PVU5UUE9JTlRET0VTTUFLRUFESUZGRVJFTkNFLS1U SEVGSVJTVFBBUlRPRlRIRU1PVU5UAAAAAKuE ------=_NextPart_000_000B_01C4162E.C6FC0B90-- From kengole@cadence.com Tue Mar 30 15:58:51 2004 From: kengole@cadence.com (Kenneth Gole) Date: Tue, 30 Mar 2004 10:58:51 -0500 Subject: [OpenAFS] amd64_linux24 AFS 1.2.11 cache problem Message-ID: <1080662331.4464.59.camel@end-skunk.cadence.com> We're running OpenAFS 1.2.11 on our Opteron machines (amd64_linux24), stock RedHat Advanced Server 3. We built OpenAFS directly from the source rpm. In general, this setup works great. However, when we try to write large files to AFS, the machine crashes with no messages or diagnostics, the kernel simply halts. If we write the same file to local disk or NFS, it works fine. The crash seems to happen when the file exceeds 70-80% of our /usr/vice/cache size (we run a 1 gigabyte cache) and when it's a core-type file (memory-mapped files seem to do it, too). Here's an example of a C program that will crash the system if the core file is written to AFS, works if written to local disk or NFS: ----------------------------------------------------- #include #include #include #include #include #include int main(void) { void * start=NULL,*base; size_t length=(3*256*1024*1024); int prot, flags=0, fd=-1; off_t offset=0; prot=(PROT_READ|PROT_WRITE); flags=MAP_SHARED|MAP_ANONYMOUS; base=mmap(start,length,prot,flags,fd,offset); printf("Our segment begins at %p, here comes the abort...\n",base); abort(); /* Generate a 756+ megabyte core file */ return 0; } ------------------------------------------------------------- However, a similar program that fwrite()'s a file of the same size as the core file works fine, even to afs: #include #include int main(void) { FILE *file; size_t size=805613568; void *p=calloc(1,size); if (file= fopen ("bigfile", "wb")) { fwrite(p,size,1,file); fclose(file); } return 0; } ------------------------------------------------------------------- Changing the size of the AFS cache masks the problem, but as soon as we again reach a file size of about 75% of the cache size, it crashes. I checked the documentation and the mailing lists, but I don't see any debug for cache manager problems. We're using the "$XLARGE" in our afs sysconfig and I've tried adding -debug and -verbose flags to afsd with no luck. This fails consistently with both smp and uniprocessor kernels, and also with OpenAFS 1.3.62. I'd appreciate any suggestions or advice on how we can get to the bottom of this problem - it's killing our productivity when our systems keep crashing. Thanks! Ken Gole Cadence Design Systems Endicott, NY kengole@cadence.com (607) 762-1342 From nneul@umr.edu Tue Mar 30 16:06:20 2004 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 30 Mar 2004 10:06:20 -0600 Subject: [OpenAFS] ftp overrides AFS permissions Message-ID: <5C51DC2B8353AB4BA2CD04B34F2EE79C3EFE0C@umr-umail1.umr.edu> That's not very safe. If all you are doing is dropping the pag, if you ever authenticate as root outside of a pag again on that box (granted, not a good idea), you'll be giving your new token to the ftp server. You should just run the ftp server in it's own pag, which can be done with the standard tools provided with an afs install without having to create a new one. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-6679 UMR Information Technology Fax: (573) 341-4216 =20 > -----Original Message----- > From: openafs-info-admin@openafs.org=20 > [mailto:openafs-info-admin@openafs.org] On Behalf Of=20 > Christopher Allen Wing > Sent: Tuesday, March 30, 2004 8:54 AM > To: J S > Cc: openafs-info@openafs.org > Subject: Re: [OpenAFS] ftp overrides AFS permissions >=20 > Sure, the usual cause of this problem is that you logged in as root, > obtained a PAG and an administrator token, and then started the FTP > server. In this case the FTP server will inherit the PAG and tokens. >=20 > The solution is to never start a daemon process as root if=20 > you have AFS > tokens. >=20 > Here is a program that when run as root will remove the current PAG: >=20 > http://www-personal.engin.umich.edu/~wingc/code/unpagsh.c >=20 >=20 >=20 > When restarting a daemon process, what I usually do first is: >=20 > 1. Become root >=20 > 2. Run 'unpagsh' to drop any PAG >=20 > 3. Run 'tokens' to make sure that the default PAG for root does > not have tokens >=20 >=20 > -Chris Wing > wingc@engin.umich.edu >=20 >=20 >=20 > On Tue, 30 Mar 2004, J S wrote: >=20 > > Hi, > > > > I have noticed that when I ftp to a host with an AFS client=20 > as my normal > > userid, I can cd/del/put into AFS directories where I don't have > > permissions. I can do this eventhough I haven't logged on=20 > to AFS. The root > > userid on this box has administrator priviledges on AFS but=20 > I'm ftp'ing with > > my own userid. > > > > Does anyone get this? > > > > Thanks for any help. > > > > Ed. >=20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >=20 >=20 From tcreedon@easystreet.com Tue Mar 30 16:14:20 2004 From: tcreedon@easystreet.com (ted creedon) Date: Tue, 30 Mar 2004 08:14:20 -0800 Subject: [OpenAFS] ftp overrides AFS permissions In-Reply-To: <5C51DC2B8353AB4BA2CD04B34F2EE79C3EFE0C@umr-umail1.umr.edu> Message-ID: <20040330161420.C4A8A294CE@smtpauth.easystreet.com> Russ Alberry has an AFS aware ftp, Russ perhaps you could post it on your website? Tedc -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Neulinger, Nathan Sent: Tuesday, March 30, 2004 8:06 AM To: Christopher Allen Wing; J S Cc: openafs-info@openafs.org Subject: RE: [OpenAFS] ftp overrides AFS permissions That's not very safe. If all you are doing is dropping the pag, if you ever authenticate as root outside of a pag again on that box (granted, not a good idea), you'll be giving your new token to the ftp server. You should just run the ftp server in it's own pag, which can be done with the standard tools provided with an afs install without having to create a new one. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-6679 UMR Information Technology Fax: (573) 341-4216 > -----Original Message----- > From: openafs-info-admin@openafs.org > [mailto:openafs-info-admin@openafs.org] On Behalf Of > Christopher Allen Wing > Sent: Tuesday, March 30, 2004 8:54 AM > To: J S > Cc: openafs-info@openafs.org > Subject: Re: [OpenAFS] ftp overrides AFS permissions > > Sure, the usual cause of this problem is that you logged in as root, > obtained a PAG and an administrator token, and then started the FTP > server. In this case the FTP server will inherit the PAG and tokens. > > The solution is to never start a daemon process as root if > you have AFS > tokens. > > Here is a program that when run as root will remove the current PAG: > > http://www-personal.engin.umich.edu/~wingc/code/unpagsh.c > > > > When restarting a daemon process, what I usually do first is: > > 1. Become root > > 2. Run 'unpagsh' to drop any PAG > > 3. Run 'tokens' to make sure that the default PAG for root does > not have tokens > > > -Chris Wing > wingc@engin.umich.edu > > > > On Tue, 30 Mar 2004, J S wrote: > > > Hi, > > > > I have noticed that when I ftp to a host with an AFS client > as my normal > > userid, I can cd/del/put into AFS directories where I don't have > > permissions. I can do this eventhough I haven't logged on > to AFS. The root > > userid on this box has administrator priviledges on AFS but > I'm ftp'ing with > > my own userid. > > > > Does anyone get this? > > > > Thanks for any help. > > > > Ed. > > _______________________________________________ > 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 From wingc@engin.umich.edu Tue Mar 30 16:16:36 2004 From: wingc@engin.umich.edu (Christopher Allen Wing) Date: Tue, 30 Mar 2004 11:16:36 -0500 (EST) Subject: [OpenAFS] ftp overrides AFS permissions In-Reply-To: <5C51DC2B8353AB4BA2CD04B34F2EE79C3EFE0C@umr-umail1.umr.edu> Message-ID: Sure, that also works. I guess there are several pieces of advice: 1. Don't get AFS tokens as root if at all possible 2. If you need to get AFS tokens as root, make sure that you obtain a new PAG first. 3. Make sure that the FTP server is behaving properly. Often, there may be PAM-related bugs. The desired behavior is: each new incoming FTP connection forks off a separate process each new FTP process obtains a separate PAG and token If the FTP server is not behaving like this, then it's likely you will have all sorts of AFS related problems. A classic bug is that the server obtains an AFS token before changing UID; in this case, it will give the token to root which is not what you want. -Chris wingc@engin.umich.edu On Tue, 30 Mar 2004, Neulinger, Nathan wrote: > That's not very safe. If all you are doing is dropping the pag, if you > ever authenticate as root outside of a pag again on that box (granted, > not a good idea), you'll be giving your new token to the ftp server. You > should just run the ftp server in it's own pag, which can be done with > the standard tools provided with an afs install without having to create > a new one. > > -- Nathan From wingc@engin.umich.edu Tue Mar 30 16:22:00 2004 From: wingc@engin.umich.edu (Christopher Allen Wing) Date: Tue, 30 Mar 2004 11:22:00 -0500 (EST) Subject: [OpenAFS] ftp overrides AFS permissions In-Reply-To: <20040330161420.C4A8A294CE@smtpauth.easystreet.com> Message-ID: vsftpd in red hat 9 seems mostly sane with its PAM support, except that it never calls PAM_DELETE_CRED so the tokens stay around forever. The PAM support in older versions of wu-ftpd was quite broken. Of course the best solution is to not run ftpd at all and just worry about openssh working properly with AFS. -Chris On Tue, 30 Mar 2004, ted creedon wrote: > Russ Alberry has an AFS aware ftp, > > Russ perhaps you could post it on your website? > > Tedc From rader@ginseng.hep.wisc.edu Tue Mar 30 16:24:47 2004 From: rader@ginseng.hep.wisc.edu (rader@ginseng.hep.wisc.edu) Date: Tue, 30 Mar 2004 10:24:47 -0600 Subject: [OpenAFS] ftp overrides AFS permissions In-Reply-To: Message from "ted creedon" of "Tue, 30 Mar 2004 08:14:20 PST." <20040330161420.C4A8A294CE@smtpauth.easystreet.com> Message-ID: <200403301624.i2UGOl714580@ginseng.hep.wisc.edu> The pam-aware ftpd-bsd is another option. Isn't that the preferred ftpd for afs? steve - - - systems & network guy high energy physics university of wisconsin > ---- Original Message ---- > From: "ted creedon" > Russ Alberry has an AFS aware ftp, > > Russ perhaps you could post it on your website? > > Tedc > > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.or > g] > On Behalf Of Neulinger, Nathan > Sent: Tuesday, March 30, 2004 8:06 AM > To: Christopher Allen Wing; J S > Cc: openafs-info@openafs.org > Subject: RE: [OpenAFS] ftp overrides AFS permissions > > That's not very safe. If all you are doing is dropping the pag, if you > ever authenticate as root outside of a pag again on that box (granted, > not a good idea), you'll be giving your new token to the ftp server. You > should just run the ftp server in it's own pag, which can be done with > the standard tools provided with an afs install without having to create > a new one. > > -- Nathan > > ------------------------------------------------------------ > Nathan Neulinger EMail: nneul@umr.edu > University of Missouri - Rolla Phone: (573) 341-6679 > UMR Information Technology Fax: (573) 341-4216 > > > > -----Original Message----- > > From: openafs-info-admin@openafs.org > > [mailto:openafs-info-admin@openafs.org] On Behalf Of > > Christopher Allen Wing > > Sent: Tuesday, March 30, 2004 8:54 AM > > To: J S > > Cc: openafs-info@openafs.org > > Subject: Re: [OpenAFS] ftp overrides AFS permissions > > > > Sure, the usual cause of this problem is that you logged in as root, > > obtained a PAG and an administrator token, and then started the FTP > > server. In this case the FTP server will inherit the PAG and tokens. > > > > The solution is to never start a daemon process as root if > > you have AFS > > tokens. > > > > Here is a program that when run as root will remove the current PAG: > > > > http://www-personal.engin.umich.edu/~wingc/code/unpagsh.c > > > > > > > > When restarting a daemon process, what I usually do first is: > > > > 1. Become root > > > > 2. Run 'unpagsh' to drop any PAG > > > > 3. Run 'tokens' to make sure that the default PAG for root does > > not have tokens > > > > > > -Chris Wing > > wingc@engin.umich.edu > > > > > > > > On Tue, 30 Mar 2004, J S wrote: > > > > > Hi, > > > > > > I have noticed that when I ftp to a host with an AFS client > > as my normal > > > userid, I can cd/del/put into AFS directories where I don't have > > > permissions. I can do this eventhough I haven't logged on > > to AFS. The root > > > userid on this box has administrator priviledges on AFS but > > I'm ftp'ing with > > > my own userid. > > > > > > Does anyone get this? > > > > > > Thanks for any help. > > > > > > Ed. > > > > _______________________________________________ > > 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 > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From rra@stanford.edu Tue Mar 30 17:01:07 2004 From: rra@stanford.edu (Russ Allbery) Date: Tue, 30 Mar 2004 09:01:07 -0800 Subject: [OpenAFS] ftp overrides AFS permissions In-Reply-To: <20040330161420.C4A8A294CE@smtpauth.easystreet.com> (ted creedon's message of "Tue, 30 Mar 2004 08:14:20 -0800") References: <20040330161420.C4A8A294CE@smtpauth.easystreet.com> Message-ID: <87isgm9smk.fsf@windlord.stanford.edu> ted creedon writes: > Russ Alberry has an AFS aware ftp, > Russ perhaps you could post it on your website? Embarassingly, it looks like no one here can find the source code. :/ (In our defense, we did this many years ago and we're trying to retire the entire service, but still. Gah.) We didn't do anything particularly complicated, though, and we didn't use PAM. We just took proftpd from a few years back, wormed our way into the area where it did password authentication, and replaced that code with code to do a setpag, a Kerberos v4 authentication, and acquire AFS tokens. PAM is a much better solution. -- Russ Allbery (rra@stanford.edu) From stephen@physics.unc.edu Tue Mar 30 18:35:43 2004 From: stephen@physics.unc.edu (Stephen Joyce) Date: Tue, 30 Mar 2004 13:35:43 -0500 (EST) Subject: [OpenAFS] Solaris servers and >1TB disks In-Reply-To: <1540498928.1080574043@mariner.pc.cs.cmu.edu> Message-ID: On Mon, 29 Mar 2004, Jeffrey Hutzelman wrote: > Not quite. A >1TB filesystem as a vice partition won't work, because vfsck > doesn't understand the modified filesystem structure required to support > this. We're working with Sun on getting this situation resolved. > > But what Stephen is asking about is several smaller filesystems on a >1TB > _disk_ (i.e. a RAID array). I see no reason why that shouldn't work; none > of our code (including vfsck) knows anything about disk labels. Jeffrey & Alf, thanks for the replies. Just to recap: do I understand correctly that a >1TB disk is OK as long as the separate /vice partitions are reasonable (read < 1TB)? I notice that solaris, by default, turns logging on for filesystems (partitions) larger than 1TB. If that is the only problem, would it suffice to simply specify "nologging" when mounting the /vice partitions?... Or is there some other issue with the filesystem on such large partitions? (note, I'm not saying it's wise to potentially need to fsck such a large partition; namei on ufs with logging is probably wisest). > -- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA Cheers, Stephen -- Stephen Joyce Systems Administrator P A N I C Physics & Astronomy Department Physics & Astronomy University of North Carolina at Chapel Hill Network Infrastructure voice: (919) 962-7214 and Computing fax: (919) 962-0480 http://www.panic.unc.edu "It never ceases to amaze me how many best scripting languages there are." --Larry Wall From alfw@slac.stanford.edu Tue Mar 30 18:42:32 2004 From: alfw@slac.stanford.edu (Alf Wachsmann) Date: Tue, 30 Mar 2004 10:42:32 -0800 (PST) Subject: [OpenAFS] Solaris servers and >1TB disks In-Reply-To: References: Message-ID: On Tue, 30 Mar 2004, Stephen Joyce wrote: > On Mon, 29 Mar 2004, Jeffrey Hutzelman wrote: > > > Not quite. A >1TB filesystem as a vice partition won't work, because vfsck > > doesn't understand the modified filesystem structure required to support > > this. We're working with Sun on getting this situation resolved. > > > > But what Stephen is asking about is several smaller filesystems on a >1TB > > _disk_ (i.e. a RAID array). I see no reason why that shouldn't work; none > > of our code (including vfsck) knows anything about disk labels. > > Jeffrey & Alf, thanks for the replies. > > Just to recap: do I understand correctly that a >1TB disk is OK as long > as the separate /vice partitions are reasonable (read < 1TB)? That is correct. I misread your original request. > I notice that solaris, by default, turns logging on for filesystems > (partitions) larger than 1TB. If that is the only problem, would it > suffice to simply specify "nologging" when mounting the /vice > partitions?... Or is there some other issue with the filesystem on such > large partitions? (note, I'm not saying it's wise to potentially need to > fsck such a large partition; namei on ufs with logging is probably wisest). There shouldn't be any other problem with these large partitions. (Disclaimer: We haven't tried this at SLAC yet - our largest partitions are ~810GB). -- Alf. ----------------------------------------------------------------------- Alf Wachsmann | e-mail: alfw@slac.stanford.edu SLAC Computing Service | Phone: +1-650-926-4802 2575 Sand Hill Road, M/S 97 | FAX: +1-650-926-3329 Menlo Park, CA 94025, USA | Office: Bldg. 50/323 ----------------------------------------------------------------------- http://www.slac.stanford.edu/~alfw (PGP) ----------------------------------------------------------------------- From jhutz@cmu.edu Tue Mar 30 19:33:01 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Tue, 30 Mar 2004 14:33:01 -0500 Subject: [OpenAFS] Solaris servers and >1TB disks In-Reply-To: References: Message-ID: <6000000.1080675181@liandra.pc.cs.cmu.edu> On Tuesday, March 30, 2004 13:35:43 -0500 Stephen Joyce wrote: > Just to recap: do I understand correctly that a >1TB disk is OK as long > as the separate /vice partitions are reasonable (read < 1TB)? Yes. > I notice that solaris, by default, turns logging on for filesystems > (partitions) larger than 1TB. If that is the only problem, would it > suffice to simply specify "nologging" when mounting the /vice > partitions?... Or is there some other issue with the filesystem on such > large partitions? (note, I'm not saying it's wise to potentially need to > fsck such a large partition; namei on ufs with logging is probably > wisest). It does, and you can turn logging off on such filesystems, but that's not sufficient. The filesystem structure is different, such that our vfsck cannot properly check and repair such a filesystem. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ulf.ziemann@prodesigncad.de Wed Mar 31 06:22:41 2004 From: ulf.ziemann@prodesigncad.de (Ulf Ziemann) Date: Wed, 31 Mar 2004 08:22:41 +0200 Subject: [OpenAFS] MS ISA-Server Message-ID: <406A63B1.2000601@prodesigncad.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have a network with 2 OpenAFS server version 1.2.11. This net was connected with a second network over IpSec-VPN. In the other net are a Linux and a Windows client. No problems at all. Now cames 2 MS ISA server. They tunnel the traffic thru the the IpSec-VPN. Normal traffic passes the 2 tunnels (IMAP/SMTP, Windows shares, FTP,...) Only AFS is the problem. I can get an token. But I can't see something under /afs . The process is blocked for a long time. No messages in /var/log/messages. It seems, the MTU are to large for the packets. I set the MTU on the servers and on the linux client to 1000 and restarted the afs server. Ping with to large size now don't work. Now the "ls /afs" returns immediately, but with an empty answer. Network Monitor on the ISA says, the AFS-Server would always send with an MTU from 14XX bytes with fragment=false and so it remove the packet.... How can I change the MTU for the afs? Are any other hints available? Ulf Ziemann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAamOp8cc/MGdmyloRAvMKAJ9SmlIeylw30P/mjjjOtlyFRaOTUwCglN/n 3HPO8pQxXH+1pSu2G+9jdao= =DrMq -----END PGP SIGNATURE----- From jaltman@columbia.edu Wed Mar 31 06:29:14 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Wed, 31 Mar 2004 01:29:14 -0500 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406A63B1.2000601@prodesigncad.de> References: <406A63B1.2000601@prodesigncad.de> Message-ID: <406A653A.90201@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms020103010406090006080205 Content-Type: multipart/alternative; boundary="------------000403030601070603080104" This is a multi-part message in MIME format. --------------000403030601070603080104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please try using the 1.3.62 client which was announced last week. http://www.openafs.org/release/openafs-1.3.62.html If you do not subscribe to openafs-announce@openafs.org. Please do so. https://lists.openafs.org/mailman/listinfo/openafs-announce Ulf Ziemann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I have a network with 2 OpenAFS server version 1.2.11. > This net was connected with a second network over IpSec-VPN. > > In the other net are a Linux and a Windows client. No problems at all. > > Now cames 2 MS ISA server. > They tunnel the traffic thru the the IpSec-VPN. > Normal traffic passes the 2 tunnels (IMAP/SMTP, Windows shares, FTP,...) > > Only AFS is the problem. > > I can get an token. But I can't see something under /afs . > The process is blocked for a long time. > No messages in /var/log/messages. > > It seems, the MTU are to large for the packets. > I set the MTU on the servers and on the linux client to 1000 and > restarted the afs server. > Ping with to large size now don't work. > > Now the "ls /afs" returns immediately, but with an empty answer. > > Network Monitor on the ISA says, the AFS-Server would always send with > an MTU from 14XX bytes with fragment=false and so it remove the > packet.... > > How can I change the MTU for the afs? Are any other hints available? > > Ulf Ziemann > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFAamOp8cc/MGdmyloRAvMKAJ9SmlIeylw30P/mjjjOtlyFRaOTUwCglN/n > 3HPO8pQxXH+1pSu2G+9jdao= > =DrMq > -----END PGP SIGNATURE----- > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --------------000403030601070603080104 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please try using the 1.3.62 client which was announced last week.

  http://www.openafs.org/release/openafs-1.3.62.html

If you do not subscribe to openafs-announce@openafs.org.  Please do so.
 
  https://lists.openafs.org/mailman/listinfo/openafs-announce
 
Ulf Ziemann wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I have a network with 2 OpenAFS server version 1.2.11.
This net was connected with a second network over IpSec-VPN.

In the other net are a Linux and a Windows client. No problems at all.

Now cames 2 MS ISA server.
They tunnel the traffic thru the the IpSec-VPN.
Normal traffic passes the 2 tunnels (IMAP/SMTP, Windows shares, FTP,...)

Only AFS is the problem.

I can get an token. But I can't see something under /afs .
The process is blocked for a long time.
No messages in /var/log/messages.

It seems, the MTU are to large for the packets.
I set the MTU on the servers and on the linux client to 1000 and
restarted the afs server.
Ping with to large size now don't work.

Now the "ls /afs" returns immediately, but with an empty answer.

Network Monitor on the ISA says, the AFS-Server would always send with
an MTU from 14XX bytes with fragment=false and so it remove the packet....

How can I change the MTU for the afs? Are any other hints available?

Ulf Ziemann

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAamOp8cc/MGdmyloRAvMKAJ9SmlIeylw30P/mjjjOtlyFRaOTUwCglN/n
3HPO8pQxXH+1pSu2G+9jdao=
=DrMq
-----END PGP SIGNATURE-----
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--------------000403030601070603080104-- --------------ms020103010406090006080205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMzMTA2MjkxNFowIwYJKoZIhvcNAQkEMRYEFGTjg+Pq31kX 5bmOZWje7FGUGCsQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAa847uD69PlpYe1FTrDeGDMZa8vYz 9WEVdx4AUrPCR5r7Gf6n+doQa8Yrmd1nUO7fyT2ZOEeUbX336UITrSb3MajuHtgfWoKXZ8Nl UlujygStrqbkjbyCAbrZ2vbOXO6zmXDdNPBA1eS74BI6bNmy66i3KCmSkGOFjO2XK+EJHBIr puww8l1BEbJM1l959qSouvwOYTed/wvnBgNJ8Yn5T0ItLIGYCXiWaIaEkQZ/IO6XWEmaNcf9 8Ncsujk1AFa1BC5v2tKkBo3IyYcqWGb/7ahpGId9RYOBUtIs9yWWLj5yO4EfgeaXIdwonWYS Bb+WZ9/01PIuJ0yWZGeGTfS/OAAAAAAAAA== --------------ms020103010406090006080205-- From ulf.ziemann@prodesigncad.de Wed Mar 31 06:53:26 2004 From: ulf.ziemann@prodesigncad.de (Ulf Ziemann) Date: Wed, 31 Mar 2004 08:53:26 +0200 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406A653A.90201@columbia.edu> References: <406A63B1.2000601@prodesigncad.de> <406A653A.90201@columbia.edu> Message-ID: <406A6AE6.4090304@prodesigncad.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The isa-server reports the "no fragment upd packets" on the server side. Did you think, a changed client would help? Ulf Jeffrey Altman wrote: | Please try using the 1.3.62 client which was announced last week. | | http://www.openafs.org/release/openafs-1.3.62.html | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAamrj8cc/MGdmyloRAjRrAJ95r1+f6ifdkEIoyeGCIk+zyHWLBACguLEo /y/n4C74KGDPxSgDx+EcZEk= =D/Zh -----END PGP SIGNATURE----- From jaltman@columbia.edu Wed Mar 31 07:32:54 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Wed, 31 Mar 2004 02:32:54 -0500 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406A6AE6.4090304@prodesigncad.de> References: <406A63B1.2000601@prodesigncad.de> <406A653A.90201@columbia.edu> <406A6AE6.4090304@prodesigncad.de> Message-ID: <406A7426.9000502@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms000807020102020203080203 Content-Type: multipart/alternative; boundary="------------040207050309090001050109" This is a multi-part message in MIME format. --------------040207050309090001050109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The 1.3.62 client allows you to adjust the max MTU size and the use of Jumbograms. Regkey: [HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters] Value : RxNoJumbo Type : DWORD {0,1} Default : 0 Variable: rx_nojumbo If enabled, does not send or indicate that we are able to send or receive RX jumbograms. Value : RxMaxMTU Type : DWORD Default : -1 Variable: rx_mtu If set to anything other than -1, uses that value as the maximum MTU supported by the RX interface. In order to enable OpenAFS to operate across the Cisco IPSec VPN client, this value must be set to 1264 or smaller. Ulf Ziemann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The isa-server reports the "no fragment upd packets" on the server side. > Did you think, a changed client would help? > > Ulf > > --------------040207050309090001050109 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The 1.3.62 client allows you to adjust the max MTU size and the use of Jumbograms.

Regkey:
[HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters]

Value   : RxNoJumbo
Type    : DWORD {0,1}
Default : 0
Variable: rx_nojumbo

  If enabled, does not send or indicate that we are able to send or
  receive RX jumbograms.

Value   : RxMaxMTU
Type    : DWORD
Default : -1
Variable: rx_mtu

  If set to anything other than -1, uses that value as the maximum MTU
  supported by the RX interface.

  In order to enable OpenAFS to operate across the Cisco IPSec VPN
  client, this value must be set to 1264 or smaller.


Ulf Ziemann wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The isa-server reports the "no fragment upd packets" on the server side.
Did you think, a changed client would help?

Ulf


--------------040207050309090001050109-- --------------ms000807020102020203080203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMzMTA3MzI1NFowIwYJKoZIhvcNAQkEMRYEFOAgKOc5wE/C 9rw+GD+nUkwZil5hMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAMYCiDGfzfnijYCOp1KefAs4DiN1A QtWcOqPO/lLnZqVo9myuk2HEdPQD9I63YL62ki3HLrpsHwNCd78tsM7FvUo9oeZlXKBB+xHx Ibrph6PWmEz81CaeLq+NkWQQMntQUtHIFxRNvHXKV7lTd3fQcw2NMSACJ28JLpJoO0TTXIYc U1CO1x7bOCEpf3wE9kvGZBGTIyuGIubDMyUtEFitPUG5XQv6fGDMtCi7EQWyO6lets986EBe XZZ2V9blWDho0iVAIfpyU2b7HkDmSIyQqGhxhGzkyiOY3NCN6xK9chL3K5MfE1xAek/Kqt7e 2xtB9fBAUVRgtbmwgntS9mAU3AAAAAAAAA== --------------ms000807020102020203080203-- From ulf.ziemann@prodesigncad.de Wed Mar 31 08:27:09 2004 From: ulf.ziemann@prodesigncad.de (Ulf Ziemann) Date: Wed, 31 Mar 2004 10:27:09 +0200 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406A7426.9000502@columbia.edu> References: <406A63B1.2000601@prodesigncad.de> <406A653A.90201@columbia.edu> <406A6AE6.4090304@prodesigncad.de> <406A7426.9000502@columbia.edu> Message-ID: <406A80DD.40102@prodesigncad.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, is there a similar solution for linux available? I have at this time no access to the windows machine. Is there some documentation for the registry settings? Ulf PS: Many thanks for the quick replies. Jeffrey Altman wrote: | The 1.3.62 client allows you to adjust the max MTU size and the use of | Jumbograms. | | Regkey: | [HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters] | | Value : RxNoJumbo | Type : DWORD {0,1} | Default : 0 | Variable: rx_nojumbo | | If enabled, does not send or indicate that we are able to send or | receive RX jumbograms. | | Value : RxMaxMTU | Type : DWORD | Default : -1 | Variable: rx_mtu | | If set to anything other than -1, uses that value as the maximum MTU | supported by the RX interface. | | In order to enable OpenAFS to operate across the Cisco IPSec VPN | client, this value must be set to 1264 or smaller. | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAaoDb8cc/MGdmyloRAua5AJwNBh0BkmbfgWjIfR40cnrdUOZywwCcC14S u61lLtG04nh4m9EsHYcNe88= =UBrN -----END PGP SIGNATURE----- From jaltman@columbia.edu Wed Mar 31 08:37:52 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Wed, 31 Mar 2004 03:37:52 -0500 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406A80DD.40102@prodesigncad.de> References: <406A63B1.2000601@prodesigncad.de> <406A653A.90201@columbia.edu> <406A6AE6.4090304@prodesigncad.de> <406A7426.9000502@columbia.edu> <406A80DD.40102@prodesigncad.de> Message-ID: <406A8360.4030608@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms060109030900050404090102 Content-Type: multipart/alternative; boundary="------------010205080002080505050608" This is a multi-part message in MIME format. --------------010205080002080505050608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The registry settings are documented in the CVS at doc/txt/winnotes/registry.txt I am not familiar enough with the Linux client to be able to answer the question. Ulf Ziemann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > is there a similar solution for linux available? > I have at this time no access to the windows machine. > Is there some documentation for the registry settings? > > Ulf > > PS: Many thanks for the quick replies. > --------------010205080002080505050608 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The registry settings are documented in the CVS at doc/txt/winnotes/registry.txt

I am not familiar enough with the Linux client to be able to answer the
question.



Ulf Ziemann wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

is there a similar solution for linux available?
I have at this time no access to the windows machine.
Is there some documentation for the registry settings?

Ulf

PS: Many thanks for the quick replies.

--------------010205080002080505050608-- --------------ms060109030900050404090102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMzMTA4Mzc1MlowIwYJKoZIhvcNAQkEMRYEFKZw47ay9CWZ Uju7y3byk8ykq4jJMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAYUy/RdSB/OHLgtfiWGGYmIKfpuAc rBfF8luTKD6N7we9ESG8sDlljWFQlnsLNiFqH8e9KS4Ez19PRFBA94VZ5vLIGLxhRQxbV1/z LFVqxg4GVDoDi/w7tGw2pUwTH1MKUaiBD5mRE27AcDLDrtplUMXhjqpajuUXiY3NaDsgm4WR FWWM4mpBR+JK6waWfEpa6EGcsxfKGreKr5eR4fsshRP0uD13RT+hFfmH3mUp6EGZ9cAAk1rJ leoZhoUJM7FH1daGMiOSuQ2mZ4tVYGxqNZS2saZJlsjnmaY9y/FvuGSsQxfF3bi2Y8aGxlb8 FaKh409FoXxC42fLsnquTgzf1QAAAAAAAA== --------------ms060109030900050404090102-- From ulf.ziemann@prodesigncad.de Wed Mar 31 13:54:16 2004 From: ulf.ziemann@prodesigncad.de (Ulf Ziemann) Date: Wed, 31 Mar 2004 15:54:16 +0200 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406A8360.4030608@columbia.edu> References: <406A63B1.2000601@prodesigncad.de> <406A653A.90201@columbia.edu> <406A6AE6.4090304@prodesigncad.de> <406A7426.9000502@columbia.edu> <406A80DD.40102@prodesigncad.de> <406A8360.4030608@columbia.edu> Message-ID: <406ACD88.4090904@prodesigncad.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeffrey Altman wrote: | | I am not familiar enough with the Linux client to be able to answer the | question. Thanks.... the win32-Client is up and running! There are some problems with the global drive mappings. But the client server communication is now alright! Somebody can give me some information about a solution for a linux client to change the MTU? Ulf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAas2G8cc/MGdmyloRApl9AKC9sH1KFnDRzDDaVnvlO1DG6YDL5gCeICzf suZWZQGAMPbIEkP59km4quU= =1ZE1 -----END PGP SIGNATURE----- From senseiwa@tin.it Wed Mar 31 14:02:26 2004 From: senseiwa@tin.it (Sensei) Date: Wed, 31 Mar 2004 16:02:26 +0200 Subject: [OpenAFS] Last very few steps: hints please! Message-ID: <406ACF72.2070305@tin.it> Hi. I'm back to terrorize you with my questions :) In my dept, we've done this: - Kerberos 5 authentication (MIT) - LDAP for information retreiving (over kerberos/gssapi) like home directories, preferred shell, office number, email... (OpenLDAP) Now, I was setting up a cell *against* kerberos. This is what I've done: On kadmin: addprinc -randkey afs addprinc -randkey afs/host.name ktadd -e des-cbc-crc:v4 afs ktadd -e des-cbc-crc:v4 afs/host.name === OK (Look at the KVNOs) asetkey add /etc/krb5.keytab afs/host.name asetkey add /etc/krb5.keytab afs === OK asetkey list kvno : key is kvno : key is All done. === OK ./bosserver -noauth & [1] 1360 [1]+ Done ./bosserver -noauth === OK ./bos setcellname host.name plm.cell === OK ./bos create -server host.name -instance ptserver -type simple -cmd /usr/afs/bin/ptserver -cell plm.cell === OK ./bos create -server host.name -instance vlserver -type simple -cmd /usr/afs/bin/vlserver -cell plm.cell === OK ./bos addhost -server host.name -host host.name -cell plm.cell -noauth === OK bos adduser -server host.name admin -cell plm.cell -noauth === OK ./bos listhosts host.name -noauth Cell name is plm.cell Host 1 is host.name === OK ./bos listkeys servername -cell plm.cell -noauth key has cksum key has cksum Key last chaged on Wed Mar All done. === OK ./pts createuser -name admin -cell plm.cell -noauth User admin has id 1 === OK ./pts adduser admin system:administrators -cell plm.cell -noauth === OK ./pts membership admin -cell plm.cell -noauth Groups admin (id: 1) is a member of: system:administrators === OK ./bos restart host.name -all -cell plm.cell -noauth === OK ./bos create -server host.name -instance fs -type fs -cmd /usr/afs/bin/fileserver -cmd /usr/afs/bin/volserver -cmd /usr/afs/bin/salvager -cell plm.cell -noauth >>> REMOVED vlserver from -cmd sequence === OK ./bos status host.name fs -long -noauth === OK ./vos create -server host.name -partition /vicepa -name root.afs -cell plm.cell -noauth Volume 274141546154 created on partition /vicepa of host.name === OK ./bos shutdown host.name -wait bos: a pioctl failed (getting tickets) bos: running unauthenticated File server restart/shutdown received at Thu Mar 18 14:55:43 2004 File server has terminated normally at Thu Mar 18 14:55:43 2004 === OK pkill bosserver === OK Edited afs.conf in order to start afs server === OK Reboot. Now, what should I do? I'd like to login from the shell (using pam) and get my ticket along with my token... I have to setup a client, right? I'm using debian woody (stable) and I have no pam_krb5afs module. I should download it right? There's no way to remain in woody? -- Sensei f u cn rd ths u r usng unx From openafs-info@openafs.org Wed Mar 31 14:45:01 2004 From: openafs-info@openafs.org (seph) Date: Wed, 31 Mar 2004 09:45:01 -0500 Subject: [OpenAFS] Re: Last very few steps: hints please! In-Reply-To: <406ACF72.2070305@tin.it> (senseiwa@tin.it's message of "Wed, 31 Mar 2004 16:02:26 +0200") References: <406ACF72.2070305@tin.it> Message-ID: > I have to setup a client, right? I'm using debian woody (stable) and I > have no pam_krb5afs module. I should download it right? There's no way > to remain in woody? bash$ apt-cache search afs | grep pam libpam-openafs-session - PAM Module to get AFS tokens and set up PAG which works fine for me. though that's just a pam module for setting up a pag, and getting tokens. you'll still need the openafs kernel modules and client. seph From danno@internet2.edu Wed Mar 31 16:35:43 2004 From: danno@internet2.edu (Dan Pritts) Date: Wed, 31 Mar 2004 11:35:43 -0500 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406ACD88.4090904@prodesigncad.de> References: <406A63B1.2000601@prodesigncad.de> <406A653A.90201@columbia.edu> <406A6AE6.4090304@prodesigncad.de> <406A7426.9000502@columbia.edu> <406A80DD.40102@prodesigncad.de> <406A8360.4030608@columbia.edu> <406ACD88.4090904@prodesigncad.de> Message-ID: <20040331163543.GA13982@internet2.edu> On Wed, Mar 31, 2004 at 03:54:16PM +0200, Ulf Ziemann wrote: > Somebody can give me some information about a solution for a linux > client to change the MTU? Have you tried just changing the MTU on the interface with something like: ifconfig eth0 mtu 1000 danno From jaltman@columbia.edu Wed Mar 31 16:46:46 2004 From: jaltman@columbia.edu (Jeffrey Altman) Date: Wed, 31 Mar 2004 11:46:46 -0500 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406ACD88.4090904@prodesigncad.de> References: <406A63B1.2000601@prodesigncad.de> <406A653A.90201@columbia.edu> <406A6AE6.4090304@prodesigncad.de> <406A7426.9000502@columbia.edu> <406A80DD.40102@prodesigncad.de> <406A8360.4030608@columbia.edu> <406ACD88.4090904@prodesigncad.de> Message-ID: <406AF5F6.2000508@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms090105060402030601000300 Content-Type: multipart/alternative; boundary="------------080007090308080003030404" This is a multi-part message in MIME format. --------------080007090308080003030404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ulf Ziemann wrote: > Thanks.... the win32-Client is up and running! > There are some problems with the global drive mappings. But the client > server communication is now alright! > The global drive mapping problem is known and is listed in the request tracker. I have a fix which is not yet checked in. There will be a new build over the weekend to fix this and several other things. Jeffrey Altman --------------080007090308080003030404 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ulf Ziemann wrote:
Thanks.... the win32-Client is up and running!
There are some problems with the global drive mappings. But the client
server communication is now alright!

The global drive mapping problem is known and is listed
in the request tracker.  I have a fix which is not yet
checked in.  There will be a new build over the weekend
to fix this and several other things.

Jeffrey Altman

--------------080007090308080003030404-- --------------ms090105060402030601000300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDMzMTE2NDY0NlowIwYJKoZIhvcNAQkEMRYEFBlpQxEnkH+Z gTEA0Gn9c+Kn7cmXMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAZLiYoIRzzUJJWT+m4OEw39qs+Jvc gkvMnV7d+PdP9bGNyosGzo7Tggm0K5kRTGWXmxJ4mbMrZUy1dc9ZwX6+8gX2XwRqsotFCU6s 780g5E96kynV8/EgSSknGXHpY0I9GR0rryohJ6V1VsRs10Yg4vsub/xutRUA3aw0kkIeriVA tCchyAART4bSA9vnESIlKgf8ixVWGHNPWwK3p3+DR9hqL/EspuxmdTkYO9FSeZnNPoBcfNs9 Oyl6sV2FT4zhbHx9Xsbwq4+IEL66f3b1seV7cMweGBH9bBR+Kle1jhe4g+OH/hh2n261NONt mKOcAt8P3S0mJvsB0Z0DUg0q2QAAAAAAAA== --------------ms090105060402030601000300-- From jhutz@cmu.edu Wed Mar 31 18:33:33 2004 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 31 Mar 2004 13:33:33 -0500 Subject: [OpenAFS] MS ISA-Server In-Reply-To: <406ACD88.4090904@prodesigncad.de> References: <406A63B1.2000601@prodesigncad.de> <406A653A.90201@columbia.edu> <406A6AE6.4090304@prodesigncad.de> <406A7426.9000502@columbia.edu> <406A80DD.40102@prodesigncad.de> <406A8360.4030608@columbia.edu> <406ACD88.4090904@prodesigncad.de> Message-ID: <403680000.1080758013@minbar.fac.cs.cmu.edu> On Wednesday, March 31, 2004 15:54:16 +0200 Ulf Ziemann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeffrey Altman wrote: >| >| I am not familiar enough with the Linux client to be able to answer the >| question. > > Thanks.... the win32-Client is up and running! > There are some problems with the global drive mappings. But the client > server communication is now alright! > > Somebody can give me some information about a solution for a linux > client to change the MTU? On a UNIX box, Linux or otherwise, you can set the interface MTU to a value not larger than the path MTU to the fileservers, and the cache manager will obey it. From kengole@cadence.com Tue Mar 30 14:38:28 2004 From: kengole@cadence.com (Kenneth Gole) Date: Tue, 30 Mar 2004 09:38:28 -0500 Subject: [OpenAFS] amd64_linux24 AFS 1.2.11 cache problem Message-ID: <1080657508.4464.55.camel@end-skunk.cadence.com> We're running OpenAFS 1.2.11 on our Opteron machines (amd64_linux24), stock RedHat Advanced Server 3. We built OpenAFS directly from the source rpm. In general, this setup works great. However, when we try to write large files to AFS, the machine crashes with no messages or diagnostics, the kernel simply halts. If we write the same file to local disk or NFS, it works fine. The crash seems to happen when the file exceeds 70-80% of our /usr/vice/cache size (we run a 1 gigabyte cache) and when it's a core-type file (memory-mapped files seem to do it, too). Here's an example of a C program that will crash the system if the core file is written to AFS, works if written to local disk or NFS: ----------------------------------------------------- #include #include #include #include #include #include int main(void) { void * start=NULL,*base; size_t length=(3*256*1024*1024); int prot, flags=0, fd=-1; off_t offset=0; prot=(PROT_READ|PROT_WRITE); flags=MAP_SHARED|MAP_ANONYMOUS; base=mmap(start,length,prot,flags,fd,offset); printf("Our segment begins at %p, here comes the abort...\n",base); abort(); /* Generate a 756+ megabyte core file */ return 0; } ------------------------------------------------------------- However, a similar program that fwrite()'s a file of the same size as the core file works fine, even to afs: #include #include int main(void) { FILE *file; size_t size=805613568; void *p=calloc(1,size); if (file= fopen ("bigfile", "wb")) { fwrite(p,size,1,file); fclose(file); } return 0; } ------------------------------------------------------------------- Changing the size of the AFS cache masks the problem, but as soon as we again reach a file size of about 75% of the cache size, it crashes. I checked the documentation and the mailing lists, but I don't see any debug for cache manager problems. We're using the "$XLARGE" in our afs sysconfig and I've tried adding -debug and -verbose flags to afsd with no luck. This fails consistently with both smp and uniprocessor kernels, and also with OpenAFS 1.3.62. I'd appreciate any suggestions or advice on how we can get to the bottom of this problem - it's killing our productivity when our systems keep crashing. Thanks! Ken Gole Cadence Design Systems Endicott, NY kengole@cadence.com (607) 762-1342 From Sergio.Gelato@astro.su.se Tue Mar 30 16:18:39 2004 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Tue, 30 Mar 2004 18:18:39 +0200 Subject: [OpenAFS] ftp overrides AFS permissions In-Reply-To: References: Message-ID: <20040330161838.GE2387@hanuman.astro.su.se> * Christopher Allen Wing [2004-03-30 09:54:02 -0500]: > The solution is to never start a daemon process as root if you have AFS > tokens. Indeed. One can think of several approaches (not all of them mutually exclusive; different daemons may have different requirements): (1) run daemons PAGless, run interactive root sessions PAGfull, and never restart a daemon directly but always via requests to another daemon such as initd (see Bernstein's daemontools for an example of this approach). If the daemon isn't a child of your interactive session, it won't inherit your PAG, terminal, etc. (2) make the daemon startup script set a new PAG to run the daemon in. (If several daemons need to share a PAG, one could run an instance of svscan or equivalent inside that PAG. Handy if one of the daemons is there to periodically renew tokens for the others.) (3) drop PAG and tokens before starting a daemon that doesn't rely on (2). Drop PAGless root tokens at any time (a PAGless cron job or daemon could do this) if any sensitive daemons are being run PAGless. > When restarting a daemon process, what I usually do first is: > 1. Become root > 2. Run 'unpagsh' to drop any PAG > 3. Run 'tokens' to make sure that the default PAG for root does > not have tokens 4. Run 'unlog' to drop any such tokens. How about doing 2. and 4. in a cron job at regular intervals? Maybe also 3., just to have a record of when someone goofed. From aij+nospam@andrew.cmu.edu Tue Mar 30 18:45:15 2004 From: aij+nospam@andrew.cmu.edu (Ivan Jager) Date: Tue, 30 Mar 2004 13:45:15 -0500 (EST) Subject: [OpenAFS] ftp overrides AFS permissions In-Reply-To: <200403301624.i2UGOl714580@ginseng.hep.wisc.edu> References: <200403301624.i2UGOl714580@ginseng.hep.wisc.edu> Message-ID: On Tue, 30 Mar 2004 rader@ginseng.hep.wisc.edu wrote: > > The pam-aware ftpd-bsd is another option. Isn't that the > preferred ftpd for afs? Does it also support kerberos authentication? I would like to be able to authenticate either with kerberos tickets, or with the password. Currently I am using heimdal's ftpd, but when using plain text authentication it only checks /etc/passwd, and doesn't get AFS tokens. Ivan From jj.walker@auckland.ac.nz Wed Mar 31 22:43:06 2004 From: jj.walker@auckland.ac.nz (Jamie Walker) Date: Thu, 1 Apr 2004 10:43:06 +1200 Subject: [OpenAFS] Dreadful metadata performance Message-ID: Since the start of the academic year, we've been experiencing very poor performance for file creates and the like. Throughput is not too bad, up to 3MB/s which is well below wire speed but still tolerable. However as an example a 66KB archive containing 10,000 empty files takes up to 10 minutes to unpack; a fresh kdevelop project can take 3-4 times as long for a ./configure in AFS space as it does in /tmp on the same machine, etc. Both clients and servers are running Debian Linux. Servers are woody, clients are mostly sarge. I discovered that volumes on a non-RAIDed ext2 vice partition on our 500MHz fileserver box were up to 3 times faster than ext3 on an Megaraid'ed RAID1 volume on the main 1.3GHz box. Moving the vicepa partitions to ext2 on the main box results in a very noticeable performance improvement but only from 'really dreadful' to 'dreadful'. This might be manageable in isolation, but when many users are logged in the problem gets a whole lot worse. This didn't happen last year, and the major changes I'm aware of are the fileserver boxes have been upgraded from a 2.4.19 kernel to 2.4.25, and the clients have been upgraded from 2.4.21 to 2.4.25, and OpenAFS upgraded on the clients to 1.2.11 (servers are 1.2.8 with patch for the Ubik time limit problem). Suggestions? It seems that moving the main fileserver box to non-RAID would probably give an improvement but obviously this isn't something to contemplate lightly! I can provide more info if given suggestions about what info would be useful. -- Phone: +64-9-373-7599 x84679 Room: 2.315, School of Engineering Email: jj.walker@auckland.ac.nz ICQ: 5632563 (or shout loudly) From shadow@dementia.org Wed Mar 31 22:47:39 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 31 Mar 2004 17:47:39 -0500 (EST) Subject: [OpenAFS] Dreadful metadata performance In-Reply-To: References: Message-ID: On Thu, 1 Apr 2004, Jamie Walker wrote: > I discovered that volumes on a non-RAIDed ext2 vice partition on our > 500MHz fileserver box were up to 3 times faster than ext3 on an > Megaraid'ed RAID1 volume on the main 1.3GHz box. Moving the vicepa > partitions to ext2 on the main box results in a very noticeable > performance improvement but only from 'really dreadful' to 'dreadful'. I heard a recommendation last week for reiserfs as a fileserver (NOT as a cache manager) backend. On the face of it it seems sensible. From jj.walker@auckland.ac.nz Wed Mar 31 23:02:48 2004 From: jj.walker@auckland.ac.nz (Jamie Walker) Date: Thu, 1 Apr 2004 11:02:48 +1200 Subject: [OpenAFS] Dreadful metadata performance In-Reply-To: References: Message-ID: <878E1E30-8367-11D8-8B00-000393B77A72@auckland.ac.nz> On 1/04/2004, at 10:47 AM, Derrick J Brashear wrote: > I heard a recommendation last week for reiserfs as a fileserver (NOT > as a > cache manager) backend. On the face of it it seems sensible. I'm investigating that on the backup box as we speak, but I'd still love to know why performance has changed so much from last year to this year. :/ -- Phone: +64-9-373-7599 x84679 Room: 2.315, School of Engineering Email: jj.walker@auckland.ac.nz ICQ: 5632563 (or shout loudly) From shadow@dementia.org Wed Mar 31 23:21:19 2004 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 31 Mar 2004 18:21:19 -0500 (EST) Subject: [OpenAFS] Dreadful metadata performance In-Reply-To: <878E1E30-8367-11D8-8B00-000393B77A72@auckland.ac.nz> References: <878E1E30-8367-11D8-8B00-000393B77A72@auckland.ac.nz> Message-ID: On Thu, 1 Apr 2004, Jamie Walker wrote: > > On 1/04/2004, at 10:47 AM, Derrick J Brashear wrote: > > > I heard a recommendation last week for reiserfs as a fileserver (NOT > > as a > > cache manager) backend. On the face of it it seems sensible. > > I'm investigating that on the backup box as we speak, but I'd still > love to know why performance has changed so much from last year to this > year. :/ semi-educated guess: your fileservers are beechwood aged now, and just like it does for beer it makes for crappy performance from ext{2,3} (worse for 3).