Re: [OpenAFS] Evaluating OpenAFS: Questions
Jeffrey Altman wrote: Rolandas Naujikas wrote: P.S. Sorry for not be able support the efforts to improve code, but I have too much work. I'm not sympathetic. We all have too much work. If you are going to rely on an open source technology and its community to provide services to your end users, then you should find the time to help. This is my personal opinion and I know there are others here that disagree with me. At the risk of sounding waffle-ish in what amounts to a "me too" post (and knowing full well I have not contributed code to OpenAFS in a long time), let me just chime in here and say... You're both right! We all have too much work to do. Not taking the time to report bugs insures that all of us will spend more time dealing with the consequences of old bugs rather than moving on to more interesting problems. In other words, you have too much work to justify _not_ supporting efforts to improve code -- i.e. reporting bugs with the tools provided. Um, yeah. Me too. -- +--+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A chicken crossing the road is poultry in motion. / +--+ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
And if you are going to help, run the latest daily build located at /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS \\afs\athena.mit.edu\user\j\a\jaltman\Public\OpenAFS http://web.mit.edu/jaltman/Public/OpenAFS/ because it fixes the deadlock situation you most likely have been experiencing. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Evaluating OpenAFS: Questions
Rolandas Naujikas wrote: We have been used OpenAFS 1.3.77 on Windows Terminal Server 2003, and it's working stable, when there works only one. But when many (~20) students with homes on AFS are trying use this server, then sometimes (randomly) access to AFS stops (early versions with hung on each access to files, now with access denied). I'm interested in debug this, but I'm limited in time. I can send (post) debug output from afsd*.log, but it is not easy reproduce. You don't have to debug it. Run the debug version of the installer and when the problem occurs attach windbg.exe to it and capture a full dump file. Place the dump file somewhere that I can access it. Make sure it is secure because it will contain all of the private info of the cache, tokens, etc. I will debug it. P.S. Sorry for not be able support the efforts to improve code, but I have too much work. I'm not sympathetic. We all have too much work. If you are going to rely on an open source technology and its community to provide services to your end users, then you should find the time to help. This is my personal opinion and I know there are others here that disagree with me. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Evaluating OpenAFS: Questions
On Thu, 13 Jan 2005, Rolandas Naujikas wrote: P.S. Sorry for not be able support the efforts to improve code, but I have too much work. But at least send the bug reports. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
Jeffrey Altman wrote: Rolandas Naujikas wrote: We are using samba gateway to afs from Windows (2003) Terminal Server, because OpenAFS client is not stable on them (lost or hung access to AFS). Rolandas Naujikas What version and did you file a bug report? Please define what lost or hung access means? OpenAFS for Windows 1.3.77 is compatible with Terminal Server. There have been bugs found in the AFS Client with regards to callbacks not being renewed due to deadlocks. As they are found, they are fixed. If you never report the bug, I can't fix the bug. I am aware of one deadlock situation in the current client which will be fixed in 1.3.78. Jeffrey Altman We have been used OpenAFS 1.3.77 on Windows Terminal Server 2003, and it's working stable, when there works only one. But when many (~20) students with homes on AFS are trying use this server, then sometimes (randomly) access to AFS stops (early versions with hung on each access to files, now with access denied). I'm interested in debug this, but I'm limited in time. I can send (post) debug output from afsd*.log, but it is not easy reproduce. Currently we are using samba (3.0) server (only for this server) with some tweaks on my FreeBSD workstation as gateway throw arla client and it's working more stable. Rolandas Naujikas P.S. Sorry for not be able support the efforts to improve code, but I have too much work. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
I'm intrigued by the thread on using samba as an AFS gateway. I understand the various reasons from wanting to 1) put most configuration and control into a server 2) add file locking semantics to afs through samba 3) avoiding a total rollout of afs clients to all users various others... I recall there used to be a product called "Syntax"? that was an smb to afs gateway. Anyone know what might have happened to them? The thing that would worry me is complexity. It seems that it means putting too much complexity at central points of failure. Seems the development efforts should be place in 1) creating a centrally manageable afs client (there are various tools like sms) 2) adding smb-like file locking semantics to afs 3) ntfs like file level acl's My experience with the AFS code on windows has been good. The recent development efforts have been astounding. Many thanks to the openafs developers for the improvements to the windows client. -- 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" ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
Rolandas Naujikas wrote: We are using samba gateway to afs from Windows (2003) Terminal Server, because OpenAFS client is not stable on them (lost or hung access to AFS). Rolandas Naujikas What version and did you file a bug report? Please define what lost or hung access means? OpenAFS for Windows 1.3.77 is compatible with Terminal Server. There have been bugs found in the AFS Client with regards to callbacks not being renewed due to deadlocks. As they are found, they are fixed. If you never report the bug, I can't fix the bug. I am aware of one deadlock situation in the current client which will be fixed in 1.3.78. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Evaluating OpenAFS: Questions
On Wed, 12 Jan 2005, Rolandas Naujikas wrote: We are using samba gateway to afs from Windows (2003) Terminal Server, because OpenAFS client is not stable on them (lost or hung access to AFS). If you had issues, did you report them? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
We are using samba gateway to afs from Windows (2003) Terminal Server, because OpenAFS client is not stable on them (lost or hung access to AFS). Rolandas Naujikas On Wed, Jan 12, 2005 at 02:39:10PM -0500, Jeffrey Altman wrote: > This is a cryptographically signed message in MIME format. > > --ms080501010709070604000100 > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > Kris Van Hees wrote: > > Actually, it is perfectly possible to have Samba get AFS tokens the normal > > way by using PAM, and letting Samba authenticate the user through pam. The > > Samba instance that serves that particular connection from a Windows client > > will then have an AFS token for the user if it was able to authenticate the > > user. This is similar to how a user can get AFS tokens by logging in on the > > Unix system directly. > > In which case you are sending passwords across the network. In my > opinion this is worse. There was once a time when the Windows OpenAFS > client was not being developed or supported where I could have justified > the notion that a Samba gateway should be used simply because the client > was too unstable to use. This is no longer true. > > Jeffrey Altman > > --ms080501010709070604000100 > 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 > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC > AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE > ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv > bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 > WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT > SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l > ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 > +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp > z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 > WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 > lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r > 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s > dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 > eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe > L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M > CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC > WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro > YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 > MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx > HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A > Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M > 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs > Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A > B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD > GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf > u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq > YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH > lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b > rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU > njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL > MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du > MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT > ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB > MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx > NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 > ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl > bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK > mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ > cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 > YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 > oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j > cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy > LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 > Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg > T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB > MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 > ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hb
Re: [OpenAFS] Evaluating OpenAFS: Questions
Sven Oehme wrote: we don't send password of the network ! we authenticate the user with windows mechanism and create a token for the user in the samba session. so you can use Kerberos authentication between ADS <-> our Samba afs gateway. I know you don't send passwords. You perform Kerberos authentication and then write a new service ticket for the user under the covers. Kris, was describing a scenario which uses password authentication to Samba. That is what I was replying to. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Evaluating OpenAFS: Questions
Sven Oehme wrote: yes do you trust your Openafs Fileservers ? they also need the key ... and if you run that in a controlled environment (a linux cluster) this is not a problem at all. Every service must have the key for itself. At the present time there is a single key for all file servers. Compromising one file server provides access to all of them. This will not necessarily be true in the future after the GSS/KCrypto RX Security Class gets deployed. we have several installations with multiple thousand users, exporting multiple T-byte of data over multiple samba hosts. btw. we work with multiple members of the samba team on that project. believe me, it works. I am glad this works for you in your environment. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Evaluating OpenAFS: Questions
> Kris Van Hees wrote: > > Actually, it is perfectly possible to have Samba get AFS tokens the normal > > way by using PAM, and letting Samba authenticate the user through pam. The > > Samba instance that serves that particular connection from a Windows client > > will then have an AFS token for the user if it was able to authenticate the > > user. This is similar to how a user can get AFS tokens by loggingin on the > > Unix system directly. > > In which case you are sending passwords across the network. In my > opinion this is worse. There was once a time when the Windows OpenAFS > client was not being developed or supported where I could have justified > the notion that a Samba gateway should be used simply because the client > was too unstable to use. This is no longer true. > > Jeffrey Altman we don't send password of the network ! we authenticate the user with windows mechanism and create a token for the user in the samba session. so you can use Kerberos authentication between ADS <-> our Samba afs gateway. i think you are doing good work with your windows client, don't misunderstand me. it's more a preference by me, to not try to manage software on a workstation, if you can do it central on the server. Sven - Dept. A141, TG/SSG EMEA AIS Strategy and Architecture Development Leader Stonehenge IBM intranet ---> http://w3.ais.mainz.de.ibm.com/stonehenge/ internet ---> http://www-5.ibm.com/services/de/storage/stonehenge.html Phone (+49)-6131-84-3151 Fax (+49)-6131-84-6708 Mobil (+49)-171-970-6664 E-Mail : [EMAIL PROTECTED]
Re: [OpenAFS] Evaluating OpenAFS: Questions
Kris Van Hees wrote: Actually, it is perfectly possible to have Samba get AFS tokens the normal way by using PAM, and letting Samba authenticate the user through pam. The Samba instance that serves that particular connection from a Windows client will then have an AFS token for the user if it was able to authenticate the user. This is similar to how a user can get AFS tokens by logging in on the Unix system directly. In which case you are sending passwords across the network. In my opinion this is worse. There was once a time when the Windows OpenAFS client was not being developed or supported where I could have justified the notion that a Samba gateway should be used simply because the client was too unstable to use. This is no longer true. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Evaluating OpenAFS: Questions
> Sven Oehme wrote: > > > > > > > > > You do not want to use an intermediary server with Samba as a go between. > > > > > > > why ? > > if the Samba Server understand's afs, this is something you want, > > because you don't have to maintain a AFS client on each System ... > > > > Sven > > First, the Samba server then needs to know the Kerberos key for AFS > in order to be able to generate tokens on behalf of the authenticated > end user. Since the Samba server is on a machine which is to be > considered more vulnerable to attack then the KDC, this should not be > allowed. yes do you trust your Openafs Fileservers ? they also need the key ... and if you run that in a controlled environment (a linux cluster) this is not a problem at all. > > Second, Samba supports SMB features such as byte range locking and > Unicode which are currently not supported by AFS file servers. > Clients will rely on the fact that the SMB server states that these > features are supported and expect them to work when the reality is > they cannot. if you use the afs built-in lock mechanism used by a samba instance, that's not a problem. the drawback is, you can't use a file at the same time exported over multiple samba instances. > > If you are willing to risk the compromise of your data both from > unauthorized access as well as from write collisions, go ahead and > use Samba as a gateway. Otherwise, stick to using a true AFS client. > > Jeffrey Altman > > we have several installations with multiple thousand users, exporting multiple T-byte of data over multiple samba hosts. btw. we work with multiple members of the samba team on that project. believe me, it works. Sven - Dept. A141, TG/SSG EMEA AIS Strategy and Architecture Development Leader Stonehenge IBM intranet ---> http://w3.ais.mainz.de.ibm.com/stonehenge/ internet ---> http://www-5.ibm.com/services/de/storage/stonehenge.html Phone (+49)-6131-84-3151 Fax (+49)-6131-84-6708 Mobil (+49)-171-970-6664 E-Mail : [EMAIL PROTECTED]
Re: [OpenAFS] Evaluating OpenAFS: Questions
On Wed, Jan 12, 2005 at 02:13:11PM -0500, Jeffrey Altman wrote: > Sven Oehme wrote: > >why ? > >if the Samba Server understand's afs, this is something you want, > >because you don't have to maintain a AFS client on each System ... > > First, the Samba server then needs to know the Kerberos key for AFS > in order to be able to generate tokens on behalf of the authenticated > end user. Since the Samba server is on a machine which is to be > considered more vulnerable to attack then the KDC, this should not be > allowed. Actually, it is perfectly possible to have Samba get AFS tokens the normal way by using PAM, and letting Samba authenticate the user through pam. The Samba instance that serves that particular connection from a Windows client will then have an AFS token for the user if it was able to authenticate the user. This is similar to how a user can get AFS tokens by logging in on the Unix system directly. > Second, Samba supports SMB features such as byte range locking and > Unicode which are currently not supported by AFS file servers. > Clients will rely on the fact that the SMB server states that these > features are supported and expect them to work when the reality is > they cannot. The feature mapping between Samba and AFS is indeed the big problem in the long run. And although it is technically possible to resolve most (if not all) of that, it is far from trivial. Kris ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
Sven Oehme wrote: > > You do not want to use an intermediary server with Samba as a go between. > why ? if the Samba Server understand's afs, this is something you want, because you don't have to maintain a AFS client on each System ... Sven First, the Samba server then needs to know the Kerberos key for AFS in order to be able to generate tokens on behalf of the authenticated end user. Since the Samba server is on a machine which is to be considered more vulnerable to attack then the KDC, this should not be allowed. Second, Samba supports SMB features such as byte range locking and Unicode which are currently not supported by AFS file servers. Clients will rely on the fact that the SMB server states that these features are supported and expect them to work when the reality is they cannot. If you are willing to risk the compromise of your data both from unauthorized access as well as from write collisions, go ahead and use Samba as a gateway. Otherwise, stick to using a true AFS client. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Evaluating OpenAFS: Questions
On Wed, Jan 12, 2005 at 07:03:09PM +0100, Sven Oehme wrote: > > You do not want to use an intermediary server with Samba as a go > > between. > > why ? > if the Samba Server understand's afs, this is something you want, because > you don't have to maintain a AFS client on each System ... Actually, yes and no. Samba can be taught to understand most of the AFS semantics with some work, and additional patches on top of the existing code base, but I still haven't seen anyone do a full mapping. You also have to deal with a few more headaches on the Samba server machine since that becomes a kind of proxy AFS client, serving the needs of a larger number of systems. If those needs are somewhat in contention with one another you might get to deal with interesting performance issues. Kris ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
> > You do not want to use an intermediary server with Samba as a go between. > why ? if the Samba Server understand's afs, this is something you want, because you don't have to maintain a AFS client on each System ... Sven - Dept. A141, TG/SSG EMEA AIS Strategy and Architecture Development Leader Stonehenge IBM intranet ---> http://w3.ais.mainz.de.ibm.com/stonehenge/ internet ---> http://www-5.ibm.com/services/de/storage/stonehenge.html Phone (+49)-6131-84-3151 Fax (+49)-6131-84-6708 Mobil (+49)-171-970-6664 E-Mail : [EMAIL PROTECTED]
RE: [OpenAFS] Evaluating OpenAFS: Questions
Derrick, Yes, it is, Python is one awsome, powerful, easy, and rapid development language ... I highly recommend it! That's too bad, well I'll keep digging around and see what I can find on the API topic. Wel as you might have gathered, I'm more building the architecture for the data and it's publishing/dissemination. Technically, anybody could use any software package they like to publish the OGC services, so long as they can read the files :) But yes, I'm quite active in the MapServer community and it's my package of choice, and I would expect to try and promote that as the preferred solution. I imagine some groups may prefer to use tools they already know, notably ArcIMS, or GeoServer, and so on ... Thanks, J.F. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Derrick J Brashear Sent: January 12, 2005 12:37 PM To: openafs-info@openafs.org Subject: RE: [OpenAFS] Evaluating OpenAFS: Questions On Wed, 12 Jan 2005 [EMAIL PROTECTED] wrote: > Derrick, > > Great information! Thank you very much. > > Personally, I'm biased towards Zope for web application frameworks. I also > love Python :) Python seems to be popular for geospatial data. > This doesn't worry me too much though, for now at least I'm going to limit > my interest to automating basic OAFS features only, and I can use Perl or > Java for that (Tasks such as registering/adding a new "data provider" to the > system for example, and triggering data replication based on such an event). > Also I suppose that if there are such bindings I could write Python ones > based on that. > > Is there an API reference somewhere? Only an outdated one, unfortunately, unless someone wants to contradict me? > Authentication: I have to admit I'm not up to speed on the details of > authentication. Here's the end-result I would hope to achieve: Users can > log into their Windows workstations and map a drive to the distributed > filesystem. To keep things easy for everyone, they mount this drive through > standard windows methods, which means through SMB. I would therefore > imagine a server that is AFS aware mounting the AFS and then sharing it back > out as a samba share for example. This also works nicely to get around > security domain issues. Problem is how to keep the users synched, if at all > necessary. There is obviously no need to have a 1:1 equivalency. most users > would probably simply have a readonly type access, that can all be done > under the same user. I can't comment to this, but > I use Windows here, but it could just as well be a Solaris server running > GIS software that needs access to it, and user log into this machine > normally by being authenticated through NIS or something like that. Well, Solaris can use PAM, you can use nis for passwd lookup but pam to authenticate the user, and all would be well. > Ah, well I'm glad to hear others have applied this type of tool to > geospatial data! I'd love to hear succes tories in this field specifically. > To get geospatial for a moment: I plan on putting OGC Web Services (At > least) on top of this data, such a WMS, WFS, and so on ... As well as a > registry. mapserver, or something else? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Evaluating OpenAFS: Questions
[EMAIL PROTECTED] wrote: Authentication: I have to admit I'm not up to speed on the details of authentication. Here's the end-result I would hope to achieve: Users can log into their Windows workstations and map a drive to the distributed filesystem. To keep things easy for everyone, they mount this drive through standard windows methods, which means through SMB. I would therefore imagine a server that is AFS aware mounting the AFS and then sharing it back out as a samba share for example. This also works nicely to get around security domain issues. Problem is how to keep the users synched, if at all necessary. There is obviously no need to have a 1:1 equivalency. most users would probably simply have a readonly type access, that can all be done under the same user. What you want to do for Windows is install OpenAFS for Windows and MIT Kerberos for Windows on the client. All of the AFS file system space becomes available to you under the UNC path format: \\AFS\cellname\path You do not want to use an intermediary server with Samba as a go between. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
RE: [OpenAFS] Evaluating OpenAFS: Questions
On Wed, 12 Jan 2005 [EMAIL PROTECTED] wrote: Derrick, Great information! Thank you very much. Personally, I'm biased towards Zope for web application frameworks. I also love Python :) Python seems to be popular for geospatial data. This doesn't worry me too much though, for now at least I'm going to limit my interest to automating basic OAFS features only, and I can use Perl or Java for that (Tasks such as registering/adding a new "data provider" to the system for example, and triggering data replication based on such an event). Also I suppose that if there are such bindings I could write Python ones based on that. Is there an API reference somewhere? Only an outdated one, unfortunately, unless someone wants to contradict me? Authentication: I have to admit I'm not up to speed on the details of authentication. Here's the end-result I would hope to achieve: Users can log into their Windows workstations and map a drive to the distributed filesystem. To keep things easy for everyone, they mount this drive through standard windows methods, which means through SMB. I would therefore imagine a server that is AFS aware mounting the AFS and then sharing it back out as a samba share for example. This also works nicely to get around security domain issues. Problem is how to keep the users synched, if at all necessary. There is obviously no need to have a 1:1 equivalency. most users would probably simply have a readonly type access, that can all be done under the same user. I can't comment to this, but I use Windows here, but it could just as well be a Solaris server running GIS software that needs access to it, and user log into this machine normally by being authenticated through NIS or something like that. Well, Solaris can use PAM, you can use nis for passwd lookup but pam to authenticate the user, and all would be well. Ah, well I'm glad to hear others have applied this type of tool to geospatial data! I'd love to hear succes tories in this field specifically. To get geospatial for a moment: I plan on putting OGC Web Services (At least) on top of this data, such a WMS, WFS, and so on ... As well as a registry. mapserver, or something else? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
RE: [OpenAFS] Evaluating OpenAFS: Questions
Derrick, Great information! Thank you very much. Personally, I'm biased towards Zope for web application frameworks. I also love Python :) This doesn't worry me too much though, for now at least I'm going to limit my interest to automating basic OAFS features only, and I can use Perl or Java for that (Tasks such as registering/adding a new "data provider" to the system for example, and triggering data replication based on such an event). Also I suppose that if there are such bindings I could write Python ones based on that. Is there an API reference somewhere? Authentication: I have to admit I'm not up to speed on the details of authentication. Here's the end-result I would hope to achieve: Users can log into their Windows workstations and map a drive to the distributed filesystem. To keep things easy for everyone, they mount this drive through standard windows methods, which means through SMB. I would therefore imagine a server that is AFS aware mounting the AFS and then sharing it back out as a samba share for example. This also works nicely to get around security domain issues. Problem is how to keep the users synched, if at all necessary. There is obviously no need to have a 1:1 equivalency. most users would probably simply have a readonly type access, that can all be done under the same user. I use Windows here, but it could just as well be a Solaris server running GIS software that needs access to it, and user log into this machine normally by being authenticated through NIS or something like that. I suspect this could prove challenging somehow :) I would want to minimize the user management over head for the corporate IT guys. The nature of the geospatial data is quite varied. Some is entirely free, some isn't (You have to pay for it). Some could also be potentially sensitive yes ... At least I can't assume it would never be. Some, although free, require licensing agreements ... And so on ... Ah, well I'm glad to hear others have applied this type of tool to geospatial data! I'd love to hear succes tories in this field specifically. To get geospatial for a moment: I plan on putting OGC Web Services (At least) on top of this data, such a WMS, WFS, and so on ... As well as a registry. Hopefully I could trigger events such as a registry update on the addition of data for example. Or make the feature server aware of it as well. Because data is distributed and replicated, I'd want said service to always use the best source possible (You've addressed this thanks!). All in all a very cool solution I think :) NOw I just have to sell it The large storage requirements might be a killer though ... We'll see. Thanks again! Cheers, J.F. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Derrick J Brashear Sent: January 12, 2005 11:31 AM To: openafs-info@openafs.org Subject: Re: [OpenAFS] Evaluating OpenAFS: Questions On Wed, 12 Jan 2005 [EMAIL PROTECTED] wrote: > A quick overview of what I'm looking at: Multiple tera-bytes (5-10?) of > geospatial data distributed among at least 2, and possibly up to 5 or 6 > different geographical locations. I need to make this data > universally/pervasively accessible, in a high-performance, fault-tolerant > manner. There will be a layer of web services on top of this, as well as > possibly a content management system if that proves sensible. An aside, I think some level of "WebSphere" was essentially this. > 1) API: Is there an API available to control OAFS related functionnality > through 3rd party applications? And if so bindings to various languages? > (I'm especially interested in Python and Java, though if there is a C/C++ I > may be willing to create my own bindings). This would be used to > potentially automate some system tasks such as scheduled or event-based > replication, user management, etc ... There is Perl distributed externally, and Java bindings distributed with versions 1.3.x. > 2) User Security: I understand that the AFS has it's own security > authentication mechanisms and database. I also often saw references to > linking the AFS security into the client's local security (/etc/passwd). That wouldn't be helpful; Certainly you could continue to list users there rather than using a directory service, but the password verification would be done with Kerberos (by getting Kerberos tickets, or AFS tokens directly) otherwise you'd be unable to speak authenticated to the AFS servers. > What about NIS? Or other PAM-based authentication? You can use PAM modules which will do Kerberos and/or AFS verification and ticket/token setting. NIS could be used for user information lookup (as a directory) but not for authentication. > I'm wondering about > integration into the corporate authentication systems,
Re: [OpenAFS] Evaluating OpenAFS: Questions
On Wed, 12 Jan 2005 [EMAIL PROTECTED] wrote: A quick overview of what I'm looking at: Multiple tera-bytes (5-10?) of geospatial data distributed among at least 2, and possibly up to 5 or 6 different geographical locations. I need to make this data universally/pervasively accessible, in a high-performance, fault-tolerant manner. There will be a layer of web services on top of this, as well as possibly a content management system if that proves sensible. An aside, I think some level of "WebSphere" was essentially this. 1) API: Is there an API available to control OAFS related functionnality through 3rd party applications? And if so bindings to various languages? (I'm especially interested in Python and Java, though if there is a C/C++ I may be willing to create my own bindings). This would be used to potentially automate some system tasks such as scheduled or event-based replication, user management, etc ... There is Perl distributed externally, and Java bindings distributed with versions 1.3.x. 2) User Security: I understand that the AFS has it's own security authentication mechanisms and database. I also often saw references to linking the AFS security into the client's local security (/etc/passwd). That wouldn't be helpful; Certainly you could continue to list users there rather than using a directory service, but the password verification would be done with Kerberos (by getting Kerberos tickets, or AFS tokens directly) otherwise you'd be unable to speak authenticated to the AFS servers. What about NIS? Or other PAM-based authentication? You can use PAM modules which will do Kerberos and/or AFS verification and ticket/token setting. NIS could be used for user information lookup (as a directory) but not for authentication. I'm wondering about integration into the corporate authentication systems, such as the Windows domains for example, or the NIS domains. A given user might have different UID's on different boxes and managing the ID match between the local password database and the AFS one could quickly get onerous. numeric uids, or the username string? 3) Because of the sheer size of the data (and the fact it will basically grow indefinitely), I would like to consider the opion of using replication as a form of backup (10TB worth of tapes, and the management overhead for all this, will likely proove prohibitive). I woulod simply make sure all data gets replicated to *at least* one other location (Available storage permitting). The web services/application layer would need to be aware of the fail overs in order to make sure the service colsest to the data is always used to avoid going over WAN links for dynamic/on-demand data use (Which takes me back to questions 1 and 2). We don't have automatic replication, though your frontend could re-replicate after any data store. As to using the closest replica, you can do this automatically by setting a priority list on the client called "server preferences"; It is by IP address of the server and the client will then prefer to fetch from the servers in the order you've specified. 4) How safe is the protocol itself? Could I mount shares accross the open internet? Is there encryption available? Basically, if a totally external organization wants to "peer" into the filesystem, can it be done safely and reliably as far as OFS is concerned (Assuming all other factors, such as network bandwith and network level security is properly managed of course). Encryption is available, but will be more interesting in a few months when more encryption types are available. Is your geospatial data sensitive? The access control issue for sharing out of AFS isn't a big deal, to the extent that you trust Kerberos to be secure. If you do have worries about that, you may also want the true Kerberos 5 which will be introduced at the same time before you share data generally. And as another aside, I will tell you that you've hit one of my interest areas; The largest use of my own home AFS cell is geospatial data. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] Evaluating OpenAFS: Questions
Hello, For a project I am working on, I am evaluating the use of a distributed filesystem as a potential solution to my problems. So far I've discovered RedHat's GFS, Coda, and OpenAFS. I've started reading up on OpenAFS and I must say I am quite impressed: The product looks mature and featureful. A quick overview of what I'm looking at: Multiple tera-bytes (5-10?) of geospatial data distributed among at least 2, and possibly up to 5 or 6 different geographical locations. I need to make this data universally/pervasively accessible, in a high-performance, fault-tolerant manner. There will be a layer of web services on top of this, as well as possibly a content management system if that proves sensible. I was wondering however if someone could answer some high-level questions about the product? 1) API: Is there an API available to control OAFS related functionnality through 3rd party applications? And if so bindings to various languages? (I'm especially interested in Python and Java, though if there is a C/C++ I may be willing to create my own bindings). This would be used to potentially automate some system tasks such as scheduled or event-based replication, user management, etc ... 1a) If there is no API, are the command line tools safe to call through a system call? Are the various return codes well documented and so on, so that I may use them integrated into an application? 2) User Security: I understand that the AFS has it's own security authentication mechanisms and database. I also often saw references to linking the AFS security into the client's local security (/etc/passwd). What about NIS? Or other PAM-based authentication? I'm wondering about integration into the corporate authentication systems, such as the Windows domains for example, or the NIS domains. A given user might have different UID's on different boxes and managing the ID match between the local password database and the AFS one could quickly get onerous. 3) Because of the sheer size of the data (and the fact it will basically grow indefinitely), I would like to consider the opion of using replication as a form of backup (10TB worth of tapes, and the management overhead for all this, will likely proove prohibitive). I woulod simply make sure all data gets replicated to *at least* one other location (Available storage permitting). The web services/application layer would need to be aware of the fail overs in order to make sure the service colsest to the data is always used to avoid going over WAN links for dynamic/on-demand data use (Which takes me back to questions 1 and 2). 4) How safe is the protocol itself? Could I mount shares accross the open internet? Is there encryption available? Basically, if a totally external organization wants to "peer" into the filesystem, can it be done safely and reliably as far as OFS is concerned (Assuming all other factors, such as network bandwith and network level security is properly managed of course). I think that's about it for now ... Thanks in advance! Jean-François Doyon Internet Service Development and Systems Support / Spécialiste de dèveloppements internet et soutien technique Canada Centre for Remote Sensing / Centre Canadien de télédétection Natural Resources Canada / Ressources naturelles Canada http://atlas.gc.ca Tel./Tél. : (613) 992-4902 Fax: (613) 947-2410 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
