From Arne.Wiebalck@cern.ch Tue Jul 3 10:00:07 2012 From: Arne.Wiebalck@cern.ch (Arne Wiebalck) Date: Tue, 3 Jul 2012 09:00:07 +0000 Subject: [OpenAFS] OpenAFS for Windows 1.7.15: NIM/Heimdal crashes Message-ID: <1AF6B081-6980-40D0-8ABD-2A4FA33FBAAB@cern.ch> Hi, We observe what seems to be two different types of NIM/Heimdal crashes when= =20 using Heimdal 1.5.1 NIM 2.0.102.907 OpenAFS for Windows 1.7.15 Windows 7 Enterprise SP1, 64 bit The first crash happens intermittently when obtaining new krb5 credentials. We have not found a way yet to reproduce it reliably, but obtaining new credentials for a couple of times will crash NIM sooner or later. We though= t it might be related to our DNS aliased AD KDC which has three machines, but it seem we run into the same crash when we limit things to one KDC. The second crash happens reliably when deselecting the 'Addressless'=20 option in the Advanced options Kerberos v5 panel. We're not really experienced with debugging this on Windows, so any hints what to look at or what other info is needed to understand what happens=20 would be greatly appreciated. Thanks, Arne =20 From dantolov@indiana.edu Tue Jul 3 21:27:02 2012 From: dantolov@indiana.edu (Danko Antolovic) Date: Tue, 3 Jul 2012 16:27:02 -0400 Subject: [OpenAFS] Transfer rates under OpenAFS client for Windows Message-ID: <251D82B5D0E944EE900DE88C2A60DCFF@ads.iu.edu> This is a multi-part message in MIME format. ------=_NextPart_000_0003_01CD5938.AD9F20A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have Windows OpenAFS client 1.7.1500 on a 32-bit machine with Windows XP and a 100 mbit/s network interface. Line rate between the client's port and the target AFS file server is ca. 96 mbit/s for UDP, in both directions (measured with iperf). When I copy a single large file (ca. 1 GB) from the server to the client machine, I see a network utilization maxed at ca. 70 mbit/s, and timing the file transfer yields a similar overall rate. When I copy the same file from the client to the server, network utilization is 30 mbit/s at the maximum. Copying is always preceded by "fs flushall". My first question is why copying from the client to the file server is so much slower (by a factor of 2 or 3) than the other way around. The other question is why the network utilization, at least as reported under Windows, never approaches the line rate, even at quiet times, but rather stays below the caps of 70 and 30 percent. The client configuration parameters are: Cache size: 800 Mbytes Chunk size: 8192 Kbytes Daemons: 16 RxMaxMTU: 9000 Sec. level: 1 Server threads: 40 Stats: 20000 entries The machine has 3.45 Gbytes of RAM, and the paging file size is set at 5.3 Gbytes. I have consulted this post: http://blog.secure-endpoints.com/2008/03/i-want-my-openafs-windows-client-to -be.html but have not been able to improve the transfer rates by tweaking the client's parameters. Thank you for any help. Danko Antolovic Principal Scientist, Research Technologies, Indiana University ------=_NextPart_000_0003_01CD5938.AD9F20A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have Windows OpenAFS client  1.7.1500 on a 32-bit machine = with Windows XP and a  100 mbit/s network interface. Line rate between = the client’s port and the target AFS file server is ca. 96 mbit/s for = UDP, in both directions (measured with iperf).

 

When I copy a single large file (ca. 1 GB) from the server to = the client machine, I see a network utilization maxed at ca. 70 mbit/s, and = timing the file transfer yields a similar overall rate. When I copy the same = file from the client to the server, network utilization is 30 mbit/s at the = maximum. Copying is always preceded by “fs = flushall”.

 

My first question is why copying from the client to the file = server is so much slower (by a factor of  2 or 3) than the other way around. = The other question is why the network utilization, at least as reported = under Windows, never approaches the line rate, even at quiet times, but rather = stays below the caps of 70 and 30 percent.

 

The client configuration parameters = are:

Cache size: 800 Mbytes

Chunk size: 8192 Kbytes

Daemons: 16

RxMaxMTU: 9000

Sec. level: 1

Server threads: 40

Stats: 20000 entries

 

The machine has 3.45 Gbytes of RAM, and the paging file size is = set at 5.3 Gbytes.

 

I have consulted this post:

http://blog.secure-endpoints.com/2008/03/i-want-my-o= penafs-windows-client-to-be.html

but have not been able to improve the transfer rates by tweaking = the client’s parameters.

 

Thank you for any help.

 

Danko Antolovic

Principal Scientist, Research = Technologies,

Indiana University

 

------=_NextPart_000_0003_01CD5938.AD9F20A0-- From jaltman@your-file-system.com Wed Jul 4 01:30:52 2012 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Tue, 03 Jul 2012 20:30:52 -0400 Subject: [OpenAFS] Transfer rates under OpenAFS client for Windows In-Reply-To: <251D82B5D0E944EE900DE88C2A60DCFF@ads.iu.edu> References: <251D82B5D0E944EE900DE88C2A60DCFF@ads.iu.edu> Message-ID: <4FF38EBC.8010001@your-file-system.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDEEC8FF3D1462C5A220032EB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/3/2012 4:27 PM, Danko Antolovic wrote: > My first question is why copying from the client to the file server is > so much slower (by a factor of 2 or 3) than the other way around. The > other question is why the network utilization, at least as reported > under Windows, never approaches the line rate, even at quiet times, but= > rather stays below the caps of 70 and 30 percent. It won't go any faster with the OpenAFS RX implementation. Jeffrey Altman --------------enigDEEC8FF3D1462C5A220032EB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJP846+AAoJENxm1CNJffh45jMH+QG14X0J6sxfwnWL8O/nLCMC HdTvpD0n8TCB4XZqVVEqOQ7YELgPe5QWlVw38cIaxh38i/jY896F6wqten0xx5zD KbcHGH/ljuQE6NOmaPioYq9qN7UUgR1KBVxGXMkUP5xB97gNcIg5sKEnwU4Iv1Nx KPS+B8pTQ6CsW56xHFRP7Uf7mPV+JFv9AIfL5r6Je/b0RncJtsBq362URuNEF9S7 25OrplMPXDB6YCRX5gkp/CU+q+d3iJxhV0+aXmA3uJE5fBkS/aW42h1OiMRRVc9T vXKVdIpbhzICK2Z29xF898pUVzyca9+o3ILj7jdlvLQq1MyHvFzMd4+5SCTwrug= =nP/0 -----END PGP SIGNATURE----- --------------enigDEEC8FF3D1462C5A220032EB-- From rmdyer@uncc.edu Wed Jul 4 02:39:56 2012 From: rmdyer@uncc.edu (Dyer, Rodney) Date: Wed, 4 Jul 2012 01:39:56 +0000 Subject: [OpenAFS] Transfer rates under OpenAFS client for Windows In-Reply-To: <4FF38EBC.8010001@your-file-system.com> References: <251D82B5D0E944EE900DE88C2A60DCFF@ads.iu.edu> <4FF38EBC.8010001@your-file-system.com> Message-ID: <18B8F39B03C7B445B4C3B97D55D4555B0B3847@RPITSEXMS2.its.uncc.edu> SSdtIG5vdCBzdXJlIGlmIHRoaXMgaW5mb3JtYXRpb24gc3RpbGwgYXBwbGllcyBoZXJlLCBidXQg YmFjayBpbiAyMDEwIEkgZGlkIHNvbWUgdGVzdGluZyBhbmQgZm91bmQgdGhhdCBzb21lIG9mIG91 ciBERUxMIGNsaWVudCBtYWNoaW5lcyB3aXRoIEludGVsIGJhc2VkICJvbiBib2FyZCIgbmV0d29y ayBjaGlwcyBwZXJmb3JtZWQgc2lnbmlmaWNhbnRseSBzbG93ZXIgb24gd3JpdGVzIHRoYW4gcmVh ZHMuICBXZSB3ZXJlIHVzaW5nIFdpbmRvd3MgWFAgUHJvIFNQMyAoMzJiaXQpLiAgVGhlIE9wZW5B RlMgY2xpZW50IHdhcyB0aGUgMS41IHNlcmllcyBhdCB0aGUgdGltZS4NCg0KQWZ0ZXIgbW9yZSBy ZXNlYXJjaCBJIGZvdW5kIHRoYXQgY2hhbmdpbmcgdGhlIHJ4TWF4TVRVIHRvIGEgdmFsdWUgb2Yg NTEyIHRvIDEwMjQgb24gb3VyIG5ldHdvcmsgaW5jcmVhc2VkIHRoZSB3cml0ZSBzcGVlZCB1cCB0 byAxNTAgcGVyY2VudC4NCg0KSWYgSSBzZXQgdGhlIHZhbHVlIHJ4TWF4TVRVIGZyb20gMTAyNCB0 byAxMDI1LCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIGNsaWVudCBkcm9wcGVkIGJ5IGF0IGxlYXN0 IGhhbGYuDQoNClRoZSBwb29yIHBlcmZvcm1hbmNlIG9ubHkgc2VlbXMgdG8gYXBwZWFyIG9uIHR3 byBtb2RlbHMgb2YgRGVsbCBjbGllbnRzLi4uDQoNCkRlbGwgT3B0aVBsZXggNzYwLCB3aXRoICJJ bnRlbChSKSA4MjU2N0xNLTMgR2lnYWJpdCBOZXR3b3JrIENvbm5lY3Rpb24iDQpEZWxsIE9wdGlQ bGV4IDc1NSwgd2l0aCAiSW50ZWwoUikgODI1NjZETS0yIEdpZ2FiaXQgTmV0d29yayBDb25uZWN0 aW9uIg0KDQpBbGwgb3RoZXIgRGVsbCBtYWNoaW5lcyB0aGF0IEkndmUgdGVzdGVkIHdpdGggdGhl ICJCcm9hZGNvbSBOZXRYdHJlbWUgNTd4eCBHaWdhYml0IENvbnRyb2xsZXIiIHdlcmUgb2sgd2l0 aCBlaXRoZXIgMCAoemVybyksIG9yIDEyNjAgc2V0IGFzICJyeE1heE1UVSIuDQoNClRoaXMgd2Fz IHRlc3RlZCBpbiBtdWx0aXBsZSBvZmZpY2VzIG9uIG11bHRpcGxlIG1hY2hpbmVzLg0KDQpOb3Jt YWxseSB0aGUgQUZTIGNsaWVudCBhdXRvbWF0aWNhbGx5IGRldGVybWluZXMgdGhlIE1heE1UVSBp ZiB0aGUgcnhNYXhNVFUgaXMgc2V0IHRvIDAuDQoNClRoZSBpc3N1ZSB3YXMgbm90IHJlYWxseSB3 aXRoIHRoZSBPcGVuQUZTIGNsaWVudCwgaXQgd2FzIHdpdGggaG93IHRoZSBJbnRlbCBuZXR3b3Jr IGRyaXZlciB3YXMgaW50ZXJhY3Rpbmcgd2l0aCBXaW5kb3dzLg0KDQpUaGVyZSB3YXMgbW9yZSBy ZXNlYXJjaCBkb25lIGFuZCBmb3VuZCB0aGF0IGNoYW5naW5nIHRoZSBXaW5kb3dzICJGYXN0U2Vu ZERhdGFncmFtVGhyZXNob2xkIiB0byBzb21ldGhpbmcgbGlrZSAxNTAwIHNvbHZlZCB0aGUgcHJv YmxlbS4gIEhvd2V2ZXIgSSB3YXMgbmV2ZXIgc3VyZSBpZiBJIHdhbnRlZCB0byBjaGFuZ2UgdGhl IE1pY3Jvc29mdCAiZGVmYXVsdCIgb24gYWxsIG91ciBtYWNoaW5lcy4NCg0KV2UgbmV2ZXIgaW1w bGVtZW50ZWQgYSBtYXNzIHJvbGwtb3V0IG5ldHdvcmsgY29uZmlndXJhdGlvbiBjaGFuZ2UgdG8g b3VyIFdpbmRvd3MgY2xpZW50IG1hY2hpbmVzIHRvIGZpeCB0aGUgcHJvYmxlbS4gIEkganVzdCBx dWlldGx5IGxldCB0aGUgcHJvYmxlbSBkcm9wIG9uIHRoZSBmbG9vci4gIFNvIHRoZSBwcm9ibGVt IHN0aWxsIGV4aXN0cyBpbiBvdXIgZW52aXJvbm1lbnQuDQoNClJvZG5leSBEeWVyDQoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvcGVuYWZzLWluZm8tYWRtaW5Ab3Bl bmFmcy5vcmcgW21haWx0bzpvcGVuYWZzLWluZm8tYWRtaW5Ab3BlbmFmcy5vcmddIE9uDQo+IEJl aGFsZiBPZiBKZWZmcmV5IEFsdG1hbg0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDAzLCAyMDEyIDg6 MzEgUE0NCj4gVG86IG9wZW5hZnMtaW5mb0BvcGVuYWZzLm9yZw0KPiBTdWJqZWN0OiBSZTogW09w ZW5BRlNdIFRyYW5zZmVyIHJhdGVzIHVuZGVyIE9wZW5BRlMgY2xpZW50IGZvciBXaW5kb3dzDQo+ IA0KPiBPbiA3LzMvMjAxMiA0OjI3IFBNLCBEYW5rbyBBbnRvbG92aWMgd3JvdGU6DQo+IA0KPiA+ IE15IGZpcnN0IHF1ZXN0aW9uIGlzIHdoeSBjb3B5aW5nIGZyb20gdGhlIGNsaWVudCB0byB0aGUg ZmlsZSBzZXJ2ZXIgaXMNCj4gPiBzbyBtdWNoIHNsb3dlciAoYnkgYSBmYWN0b3Igb2YgIDIgb3Ig MykgdGhhbiB0aGUgb3RoZXIgd2F5IGFyb3VuZC4gVGhlDQo+ID4gb3RoZXIgcXVlc3Rpb24gaXMg d2h5IHRoZSBuZXR3b3JrIHV0aWxpemF0aW9uLCBhdCBsZWFzdCBhcyByZXBvcnRlZA0KPiA+IHVu ZGVyIFdpbmRvd3MsIG5ldmVyIGFwcHJvYWNoZXMgdGhlIGxpbmUgcmF0ZSwgZXZlbiBhdCBxdWll dCB0aW1lcywNCj4gPiBidXQgcmF0aGVyIHN0YXlzIGJlbG93IHRoZSBjYXBzIG9mIDcwIGFuZCAz MCBwZXJjZW50Lg0KPiANCj4gSXQgd29uJ3QgZ28gYW55IGZhc3RlciB3aXRoIHRoZSBPcGVuQUZT IFJYIGltcGxlbWVudGF0aW9uLg0KPiANCj4gSmVmZnJleSBBbHRtYW4NCg0K From jaltman@your-file-system.com Wed Jul 4 05:37:10 2012 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Wed, 04 Jul 2012 00:37:10 -0400 Subject: [OpenAFS] Transfer rates under OpenAFS client for Windows In-Reply-To: <4FF38EBC.8010001@your-file-system.com> References: <251D82B5D0E944EE900DE88C2A60DCFF@ads.iu.edu> <4FF38EBC.8010001@your-file-system.com> Message-ID: <4FF3C876.4090407@your-file-system.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC553C7C3B55B6604DC6DDFCA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/3/2012 8:30 PM, Jeffrey Altman wrote: > On 7/3/2012 4:27 PM, Danko Antolovic wrote: >=20 >> My first question is why copying from the client to the file server is= >> so much slower (by a factor of 2 or 3) than the other way around. The= >> other question is why the network utilization, at least as reported >> under Windows, never approaches the line rate, even at quiet times, bu= t >> rather stays below the caps of 70 and 30 percent. >=20 > It won't go any faster with the OpenAFS RX implementation. to provide additional details. The windows cache manager stores a file in 4K buffers. In order to write a chunk to the file server, the client must collect and lock the appropriate set of buffers. Then the cache manager must obtain a set of packet buffers from RX and copy the data into the packet buffers. The packet buffers and file buffers are not aligned so the copies are quite expensive. Then the packet data must be processed for authentication and perhaps encryption. Finally the packet data is copied once more into the network packet buffers. The OpenAFS rx stack does not provide a mechanism by which the cache manager can lend the file buffers for use as packet buffers. Such an implementation cannot be implemented in the existing RX implementation because rx objects are not reference counted. This process is much less efficient than the unix cache manager but is more flexible. The AFS cache to Windows system (page) cache interface is very fast and can support up to 800MB/second transfers. The rx interface is the current bottleneck. Jeffrey Altman --------------enigC553C7C3B55B6604DC6DDFCA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJP88h5AAoJENxm1CNJffh4iHoIANFO/fP8F+NbqREct4dVoHOp i59qWe8lWSpJVHcFJUkuHcnJ85gGGSu0XKj00IeMdcRbZm2nuAjvQhT1f8hvg2RZ IrZo5lefDCHiQ9UFHNM6N31b2Ddz4CZMFOaDsk/t5vTO1feSqTrBjEhf5zgOcfdn IXDAxVDefLIiwiM87hD/hCkyMZ/ASmLJ90SiZ9jPcZYopu0er702W6ISioR4z3tD HQs8zvp42bF7FZZKh5iT5eLCw3GmgNisml7FAdY6Y0ffykGHfQjiZoWLGtCfXHu3 IWKHoiuhcxYN7mYToe5HxwGGvPC6lPBtq2d0G3ZLR6Br88ZBkjW6jlh+jQLyVXQ= =ntU3 -----END PGP SIGNATURE----- --------------enigC553C7C3B55B6604DC6DDFCA-- From ayvango@zoho.com Wed Jul 4 09:21:38 2012 From: ayvango@zoho.com (ayvango) Date: Wed, 04 Jul 2012 01:21:38 -0700 Subject: [OpenAFS] installing openafs to windows xp sp3 32bit In-Reply-To: <9324933.496209.1340978440424.JavaMail.sas2@172.29.249.242> References: <2046371383.186037.1340803245266.JavaMail.sas2@172.29.249.242> <4FED2D6F.8030407@secure-endpoints.com> <1275805596.480680.1340970989683.JavaMail.sas2@172.29.249.242> <9324933.496209.1340978440424.JavaMail.sas2@172.29.249.242> Message-ID: <2065583864.87724.1341390098792.JavaMail.sas2@172.29.249.242> the recipe worked on xp sp3: no heimdal, only KFW openafs 1.7.1.5 manually delete entries from HKEY_LOCAL_MACHINE\SOFTWARE\OpenAFS\Client\Freelance From OpenAFS Wed Jul 4 16:14:30 2012 From: OpenAFS (Jeffrey Altman) Date: Wed, 04 Jul 2012 11:14:30 -0400 Subject: [OpenAFS] Changing RXAFS_GetVolumeStatus access check to support volume lock down Message-ID: <4FF45DD6.6060000@your-file-system.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig33AA9F612AD432B54A610609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Many sites over the last two years have focused energy on locking down their cells. This is being done to protect against information leakage and to protect the organization from end users that do not appreciate the consequences of changing the access control lists. Some sites have made the decision that volumes assigned to end users will not be owned by the user and that the volume root directory will only ever have (l)ookup. All directories the user can read or write to in the volume will be subdirectories. This approach works fine for the UNIX clients but results in some strange behaviors with the 1.7.x Windows clients. The 1.7.x Windows clients treat each AFS volume as its own file system object. The benefits of this approach are many but one of the primary ones is that each file system has its own block allocations, blocks in use counters, and per user quotas. In 1.6 and prior releases the entirety of the \\AFS name space was treated as a single file system and the client lied to Windows about the size of the file system and the amount of free space= =2E The RPC that is used to obtain the volume statistics from the file server is RXAFS_GetVolumeStatus. This RPC returns a subset of the information displayed by "vos examine " but is intended for use by AFS clients. The specific fields that are returned are: Message of the day (if any) Offline message (if any) Online flag InService flag Blessed flag NeedsSalvage flag Type MinQuota MaxQuota BlocksInUse PartBlocksAvail PartMaxBlocks While "vos examine" can obtain this information without any form of authentication, the IBM/OpenAFS file servers have always required that the [un]authenticated caller have (r)ead permission on the root directory of the volume. As a result, users whom only have (l)ookup permission to the root directory but write permission to subdirectories are permitted to write data but must do so blind with regards to the amount of free space or free quota. One side effect of writing blind on a Windows system with a large amount of unused memory is that Windows will happily write the entire file into the system page cache before flushing the data to disk on the last handle close. As a result, an application can believe it has successfully written the data only to have it be tossed out the window when it turns out there is no space. By the time the last handle is closed it is too late to return an error to the application. Lars discovered this problem back in April. As a result the Windows client now performs an explicit free space check on each extending write. While not fool proof, such a check does permit the explorer shell and applications to deliver meaningful errors to the end user while preventing unexpected data loss. Unfortunately, a meaningful free space and free quota check requires the ability to successfully issue the RXAFS_GetVolumeStatus RPC. If the volume is locked down for the user such that the user only has (l)ookup privilege it will fail. I believe that the permission check enforced by the file server is incorrect. The correct permission check should be for PRSFS_LOOKUP and not PRSFS_READ. If the client can enumerate the root directory of the volume it should be able to obtain the volume statistics. Not that they are used any longer but what use is setting the Message of the Day and the Offline reason messages on a volume if a subset of the clients that are permitted to access the volume cannot read them? The protocol documentation provided by IBM does not discuss the required permissions or the rationale for them. I believe the current check for PRSFS_READ is a coding error and it should be fixed. As noted previously, all of the information is publicly available via "vos examine". As a result making this change does not create an additional information exposure. In gerrit, http://gerrit.openafs.org/#change,7705 contains the patchset to make this change. Please send all follow-ups to this e-mail to openafs-info@openafs.org. Let the discussion of the merits of this change begin. Jeffrey Altman --------------enig33AA9F612AD432B54A610609 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJP9F3cAAoJENxm1CNJffh4/HAIAMIwRJDQ2xZOa15IgthruK4s UjpybxNAg3qhcv1H/pyMHBExf7Qml85mJnqBCRTpu6n8KdN+/wHSgimdl0sWEHOG wnAqsx+P1I1ZL21WyzGK26zhqWJ7k1X6mTy/4E2KUGCyy0lCSYUMqnSL2mw6WoWv AbeucJnPRWxSeXlHHHtQe6PP0ACPX/EzwFuVQ+7L3WagH2Fwv+apmbo7/GsuJTak 2Ff23QmIk8fEANC4NdjHg+xp8jX23O4WHhEjXn9Bckc6s5FcQ3RAExDfH4RJL7IX Xcl2ZLRczOIZkaupBNGOpTKLGgYm4KKsgc53TuAUJseiDaOQNsmOiZyVmSM7kKs= =uB7O -----END PGP SIGNATURE----- --------------enig33AA9F612AD432B54A610609-- From jhutz@cmu.edu Thu Jul 5 18:23:31 2012 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 05 Jul 2012 13:23:31 -0400 Subject: [OpenAFS] Re: [AFS3-std] Changing RXAFS_GetVolumeStatus access check to support volume lock down In-Reply-To: <4FF45DD6.6060000@your-file-system.com> References: <4FF45DD6.6060000@your-file-system.com> Message-ID: <1341509011.3279.811.camel@destiny.pc.cs.cmu.edu> On Wed, 2012-07-04 at 11:14 -0400, Jeffrey Altman wrote: > The RPC that is used to obtain the volume statistics from the file > server is RXAFS_GetVolumeStatus. This RPC returns a subset of the > information displayed by "vos examine " but is intended for use > by AFS clients. Well, not entirely. IIRC, it's quite a lot older than that, and predates the concept of a volserver or volume location server. In those days, the fileserver was the _only_ server that touched volumes; doing administrative volume operations required separate utilities on the fileserver, and moving volumes must have been a royal pain. > I believe that the permission check enforced by the file server is > incorrect. The correct permission check should be for PRSFS_LOOKUP and > not PRSFS_READ. If the client can enumerate the root directory of the > volume it should be able to obtain the volume statistics. Not that they > are used any longer but what use is setting the Message of the Day and > the Offline reason messages on a volume if a subset of the clients that > are permitted to access the volume cannot read them? In fact, the offline reason message is only ever set on an offline volume, which the fileserver cannot even access. I think it is fine to skip access control checks on this call entirely. As you point out, the information available via this RPC is also available to unauthenticated clients via the volserver. I do not believe this is a standardization issue. The meaning of some access control bits _as they apply to vnodes_ must be standardized, as clients rely on those bits when implementing access controls on cached objects shared between users. And of course, their representation on the wire must be standardized in order for the tools and interfaces used to manipulate vnode access controls to interoperate. However, the precise application of access controls to non-cacheable operations, volume-level operations, and administrative operations is not standardized and does not need to be standardized in order to obtain interoperability. Thus, I believe the present question is entirely a matter for the implementation and, perhaps, local policy. As such, I've moved afs3-standardization to the Bcc line. Please feel free to move it back in replies, but only if you actively disagree with my position that this is not a standardization issue. -- Jeff From rmdyer@uncc.edu Thu Jul 5 21:47:59 2012 From: rmdyer@uncc.edu (Dyer, Rodney) Date: Thu, 5 Jul 2012 20:47:59 +0000 Subject: [OpenAFS] Changing RXAFS_GetVolumeStatus access check to support volume lock down In-Reply-To: <4FF45DD6.6060000@your-file-system.com> References: <4FF45DD6.6060000@your-file-system.com> Message-ID: <18B8F39B03C7B445B4C3B97D55D4555B0B3BC6@RPITSEXMS2.its.uncc.edu> MS4gIEhvdyB3aWxsIHRoaXMgY2hhbmdlIGFmZmVjdCBhbnkgb2xkZXIgY2xpZW50cywgaWYgc28/ DQoNCjIuICBUaGlzIGNoYW5nZSBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlICJwcm9kdWN0aW9uIiBz ZXJ2ZXIgYnJhbmNoPw0KDQpSb2RuZXkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBvcGVuYWZzLWluZm8tYWRtaW5Ab3BlbmFmcy5vcmcgW21haWx0bzpvcGVuYWZzLWlu Zm8tDQo+IGFkbWluQG9wZW5hZnMub3JnXSBPbiBCZWhhbGYgT2YgSmVmZnJleSBBbHRtYW4NCj4g U2VudDogV2VkbmVzZGF5LCBKdWx5IDA0LCAyMDEyIDExOjE1IEFNDQo+IFRvOiBPcGVuQUZTOyBv cGVuYWZzLWRldmVsOyBhZnMzLXN0YW5kYXJkaXphdGlvbkBvcGVuYWZzLm9yZw0KPiBTdWJqZWN0 OiBbT3BlbkFGU10gQ2hhbmdpbmcgUlhBRlNfR2V0Vm9sdW1lU3RhdHVzIGFjY2VzcyBjaGVjayB0 byBzdXBwb3J0DQo+IHZvbHVtZSBsb2NrIGRvd24NCj4gDQpbcm1keWVyJ3MgY29tbWVudF0gDQo8 c25pcHBlZCBmb3IgYnJldml0eT4NCg0KPiBJbiBnZXJyaXQsIGh0dHA6Ly9nZXJyaXQub3BlbmFm cy5vcmcvI2NoYW5nZSw3NzA1IGNvbnRhaW5zIHRoZSBwYXRjaHNldCB0byBtYWtlIHRoaXMNCj4g Y2hhbmdlLg0KPiANCj4gUGxlYXNlIHNlbmQgYWxsIGZvbGxvdy11cHMgdG8gdGhpcyBlLW1haWwg dG8gb3BlbmFmcy1pbmZvQG9wZW5hZnMub3JnLg0KPiANCj4gTGV0IHRoZSBkaXNjdXNzaW9uIG9m IHRoZSBtZXJpdHMgb2YgdGhpcyBjaGFuZ2UgYmVnaW4uDQo+IA0KPiBKZWZmcmV5IEFsdG1hbg0K PiANCg0K From dantolov@indiana.edu Thu Jul 5 22:26:28 2012 From: dantolov@indiana.edu (Danko Antolovic) Date: Thu, 5 Jul 2012 17:26:28 -0400 Subject: [OpenAFS] Transfer rates under OpenAFS client for Windows In-Reply-To: <18B8F39B03C7B445B4C3B97D55D4555B0B3847@RPITSEXMS2.its.uncc.edu> References: <251D82B5D0E944EE900DE88C2A60DCFF@ads.iu.edu> <4FF38EBC.8010001@your-file-system.com> <18B8F39B03C7B445B4C3B97D55D4555B0B3847@RPITSEXMS2.its.uncc.edu> Message-ID: <5CF355D925FD4F9BA85B283AED0B4BB1@ads.iu.edu> The parameter RxMaxMTU makes a difference: when it is set to 1024, using Intel 82567LM NIC, network utilization is close to 100% for both reads and writes with Windows AFS client. Thanks for the germane information, Rodney. My system configuration: Dell Latitude, 2.53 GHz, 32-bit, 3.45 GByte RAM, 100 mbit/s Ethernet port, Intel 82567LM Gigabit NIC. Windows XP, paging file size is 5302 MBytes, although that is probably not critical. Open AFS client version 1.7.1500. This set of AFS client configuration parameters works reasonably well on my system: Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Param eters Class Name: Last Write Time: 7/5/2012 - 4:17 PM Value 0 Name: HideDotFiles Type: REG_DWORD Data: 0x1 Value 1 Name: Type: REG_SZ Data: Value 2 Name: IsGateway Type: REG_DWORD Data: 0x0 Value 3 Name: RxMaxMTU Type: REG_DWORD Data: 0x400 Value 4 Name: NetbiosName Type: REG_SZ Data: AFS Value 5 Name: Cell Type: REG_SZ Data: iu.edu Value 6 Name: MountRoot Type: REG_SZ Data: /afs Value 7 Name: NoFindLanaByName Type: REG_DWORD Data: 0x1 Value 8 Name: FreelanceClient Type: REG_DWORD Data: 0x1 Value 9 Name: UseDNS Type: REG_DWORD Data: 0x1 Value 10 Name: SecurityLevel Type: REG_DWORD Data: 0x1 Value 11 Name: SMBAuthType Type: REG_DWORD Data: 0x2 Value 12 Name: CacheSize Type: REG_DWORD Data: 0xc3500 Value 13 Name: ChunkSize Type: REG_DWORD Data: 0x15 Value 14 Name: ServerThreads Type: REG_DWORD Data: 0x28 Value 15 Name: Daemons Type: REG_DWORD Data: 0x10 Value 16 Name: Stats Type: REG_DWORD Data: 0x4e20 -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Dyer, Rodney Sent: Tuesday, July 03, 2012 9:40 PM To: jaltman@your-file-system.com; openafs-info@openafs.org Subject: RE: [OpenAFS] Transfer rates under OpenAFS client for Windows I'm not sure if this information still applies here, but back in 2010 I did some testing and found that some of our DELL client machines with Intel based "on board" network chips performed significantly slower on writes than reads. We were using Windows XP Pro SP3 (32bit). The OpenAFS client was the 1.5 series at the time. After more research I found that changing the rxMaxMTU to a value of 512 to 1024 on our network increased the write speed up to 150 percent. If I set the value rxMaxMTU from 1024 to 1025, the performance of the client dropped by at least half. The poor performance only seems to appear on two models of Dell clients... Dell OptiPlex 760, with "Intel(R) 82567LM-3 Gigabit Network Connection" Dell OptiPlex 755, with "Intel(R) 82566DM-2 Gigabit Network Connection" All other Dell machines that I've tested with the "Broadcom NetXtreme 57xx Gigabit Controller" were ok with either 0 (zero), or 1260 set as "rxMaxMTU". This was tested in multiple offices on multiple machines. Normally the AFS client automatically determines the MaxMTU if the rxMaxMTU is set to 0. The issue was not really with the OpenAFS client, it was with how the Intel network driver was interacting with Windows. There was more research done and found that changing the Windows "FastSendDatagramThreshold" to something like 1500 solved the problem. However I was never sure if I wanted to change the Microsoft "default" on all our machines. We never implemented a mass roll-out network configuration change to our Windows client machines to fix the problem. I just quietly let the problem drop on the floor. So the problem still exists in our environment. Rodney Dyer > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On > Behalf Of Jeffrey Altman > Sent: Tuesday, July 03, 2012 8:31 PM > To: openafs-info@openafs.org > Subject: Re: [OpenAFS] Transfer rates under OpenAFS client for Windows > > On 7/3/2012 4:27 PM, Danko Antolovic wrote: > > > My first question is why copying from the client to the file server is > > so much slower (by a factor of 2 or 3) than the other way around. The > > other question is why the network utilization, at least as reported > > under Windows, never approaches the line rate, even at quiet times, > > but rather stays below the caps of 70 and 30 percent. > > It won't go any faster with the OpenAFS RX implementation. > > Jeffrey Altman :?? From jaltman@your-file-system.com Thu Jul 5 23:44:40 2012 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Thu, 05 Jul 2012 18:44:40 -0400 Subject: [OpenAFS] Changing RXAFS_GetVolumeStatus access check to support volume lock down In-Reply-To: <18B8F39B03C7B445B4C3B97D55D4555B0B3BC6@RPITSEXMS2.its.uncc.edu> References: <4FF45DD6.6060000@your-file-system.com> <18B8F39B03C7B445B4C3B97D55D4555B0B3BC6@RPITSEXMS2.its.uncc.edu> Message-ID: <4FF618D8.6030305@your-file-system.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA8835C851E85703D58F118BC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/5/2012 4:47 PM, Dyer, Rodney wrote: > 1. How will this change affect any older clients, if so? Any client that doesn't issue the RPC will not be affected. Any client that does issue the RPC will now have it succeed instead of fa= il. The point of this change is to permit sites that are tightening the access control in their volumes to do so. > 2. This change is appropriate for the "production" server branch? If my cell is one that is locking down volumes such that users only have (l)ookup access to volume roots, I would be applying the patch regardless of whether or not OpenAFS does. That said I believe this patch is appropriate for 1.6.2. Jeffrey Altman --------------enigA8835C851E85703D58F118BC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJP9hjeAAoJENxm1CNJffh4zIMH/2Fc6VTbvQe80CXEzXCkJQXd 63RGfD1+Ok6ACTdVEAjtoBrWtOXWN/iQXcmWsAtnPopLs/p+F3ElELe6L3ZCaJxW oDu41Wckf5QUO8JSJuUw6iJr7ssyV4SDxB9Hqc/u1BBVGcGin+KaIqYUP4gMxAuU eZNdrEHOeACPgEl8P7r4W20i3ljKqC/KeaF/Co+zAWsFG8q5vxLXX7l49X1fPYy6 uh1cbzFSSQLpTDSukB3K/4DlGjzySn8Ey4oBJT3MPnw+7g1faSyWLmogkChW3rNR aERbdreQeoGMw6UhNJjMgWAazugoi8KwPDBmvqYoBJ53rw0vgu9y0w1b2XgW8Iw= =XPRm -----END PGP SIGNATURE----- --------------enigA8835C851E85703D58F118BC-- From kaduk@MIT.EDU Fri Jul 6 03:56:19 2012 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 5 Jul 2012 22:56:19 -0400 (EDT) Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: On Wed, 27 Jun 2012, Tim Gustafson wrote: >> I just sent off a (believed to be final) patch to get 1.6.1 in the freebsd >> ports collection this morning; it should hit the ports tree within a day or >> two. >> That sharball will not work for recent versions of freebsd, as it does not >> include the OS support for 8.3, 8-stable, 9-stable, or 10-current. > > Awesome; thanks. I'll just wait for the updated port then. Hi Tim, The openafs entry in the ports collection has just been updated; please give it a shot at your convenience and report back. Sorry for the delay; it was longer than I expected. Thanks, Ben From jayen@science.unsw.edu.au Fri Jul 6 08:31:08 2012 From: jayen@science.unsw.edu.au (Jayen Ashar) Date: Fri, 6 Jul 2012 17:31:08 +1000 Subject: [OpenAFS] token lifetime In-Reply-To: References: <1058035206.28454.8.camel@rich.habitat.thewallacepack.net> Message-ID: On Sun, Jul 13, 2003 at 5:26 AM, Derrick J Brashear wrote: > On Sat, 12 Jul 2003, Richard Wallace wrote: > >> Since it is a home network I wanted to lengthen the lifetime of the krb5 >> tickets and afs tokens. Just to have a nice round number, I went with a >> year for now. I made the modifications to the kdc.conf file so max_life >> and max_renewable_life are both "365d 0h 0m 0s". I set the lifetime on >> all the principals in the krb5 database and changed the configuration of >> pam_krb5afs in the krb5.conf file to reflect these changes. > > krb4 with the afs lifetime extensions can do a life of up to 30 days, or > unlimited. nothing in between. plus, translating something which is that > long may not work the way you expect, anyway. How can I do a life of unlimited (with krb5)? I made the modifications to the kdc.conf file so max_life and max_renewable_life are both "0d". I set the lifetime on all the principals in the krb5 database and changed the configuration of pam_krb5afs in the krb5.conf file to reflect these changes. I can see the afs service ticket and token expire on 03:14:07 UTC on Tuesday, 19 January 2038 (which I assume represents "unlimited"). The openafs server is, however, rejecting the token outright. Thanks, Jayen >> >> Its seems the afs token has a max life of a month, but I haven't found >> anywhere that this is set. Any ideas? > > the variable used to represent the life doesn't go any higher than that. From jaltman@secure-endpoints.com Fri Jul 6 09:08:18 2012 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 06 Jul 2012 04:08:18 -0400 Subject: [OpenAFS] token lifetime In-Reply-To: References: <1058035206.28454.8.camel@rich.habitat.thewallacepack.net> Message-ID: <4FF69CF2.2070805@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05E2B0C8EB7375500D1D8822 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, July 06, 2012 3:31:08 AM, Jayen Ashar wrote: > How can I do a life of unlimited (with krb5)? I made the > modifications to the kdc.conf file so max_life and max_renewable_life > are both "0d". I set the lifetime on all the principals in the krb5 > database and changed the configuration of pam_krb5afs in the krb5.conf > file to reflect these changes. I can see the afs service ticket and > token expire on 03:14:07 UTC on Tuesday, 19 January 2038 (which I > assume represents "unlimited"). The openafs server is, however, > rejecting the token outright. The code in question is tkt_DecodeTicket5() in src/rxkad/ticket5.c and tkt_CheckTimes() in src/rxkad/ticket.c. If the 'end' value is not exactly NEVERDATE (0xFFFFFFFF) and ('end' - 'start' is greater than 30 days, the token will be rejected. --------------enig05E2B0C8EB7375500D1D8822 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJP9pz1AAoJENxm1CNJffh4UEUIAOFX+v7Wii1eVGZQ6d+iCSH4 hlu5L0poBdjBl2R3fRiJ/CrfWwRwxycEYFGV9r7aZEfDAvT3z6U1iR/xSqepcX1E ANwK1zNfxj3avEkUij2XnYR3k2W3WbB/xFrBelG77xUQb1eRj1bIUFmfwOC+a6k4 iZXG2Lyk58WAN9dreEr2mRuppjM7oUxI6gtL31KUX1yyz9Tere8cL4W/pXPcz8Pz xGipLG7f90jMtSaF8P6hfdNzGVEZ30Ti3ttYqz9QIumgZYiXJuSESJC9i0BMBCyL a5613TQDNa9M9IpbIK0a8f9W6/C0yOWdVSNOaPOCqGjROfCW+oDLZ748rGFwF5U= =nOgo -----END PGP SIGNATURE----- --------------enig05E2B0C8EB7375500D1D8822-- From jayen@science.unsw.edu.au Fri Jul 6 09:44:46 2012 From: jayen@science.unsw.edu.au (Jayen Ashar) Date: Fri, 6 Jul 2012 18:44:46 +1000 Subject: [OpenAFS] token lifetime In-Reply-To: <28723e2d748c4dbdb136f6aa2b1a0362@INFPWXH002.ad.unsw.edu.au> References: <1058035206.28454.8.camel@rich.habitat.thewallacepack.net> <28723e2d748c4dbdb136f6aa2b1a0362@INFPWXH002.ad.unsw.edu.au> Message-ID: On Fri, Jul 6, 2012 at 6:08 PM, Jeffrey Altman wrote: > The code in question is tkt_DecodeTicket5() in src/rxkad/ticket5.c and > tkt_CheckTimes() in src/rxkad/ticket.c. If the 'end' value is not > exactly NEVERDATE (0xFFFFFFFF) and ('end' - 'start' is greater than > 30 days, the token will be rejected. Can I do anything (without changing code) to make the end 0xFFFFFFFF? As far as I can set, the end is only 0x7FFFFFFF. If not, is it reasonable to change the 'end' - 'start' to 180 days? Thanks, Jayen From wrbeaudo@ncsu.edu Fri Jul 6 16:24:04 2012 From: wrbeaudo@ncsu.edu (Billy Beaudoin) Date: Fri, 6 Jul 2012 11:24:04 -0400 Subject: [OpenAFS] Windows Integrated Login Fails w/ Invalid argument error Message-ID: --0015175cba10b92d0804c42ada81 Content-Type: text/plain; charset=ISO-8859-1 For users who do not previously have a local profile on a client (not using roaming profiles), I'm getting an "Integrated login failed:Invalid argument" error. Once the user has logged in once all subsequent logins work and using NIM works. Its just the initial login. But since I'm working on student labs, that's pretty much every login. I enabled debugging for integrated login and a couple log entries back KFW_AFS_get_cred has a code=[22] but I've not been able to track that back through the code to figure out which call is failing. Heimdal 1.5.1 NIM 2.0.102.907 OpenAFS for Windows 1.7.15 Windows 7 Enterprise SP1, 64 bit Billy Beaudoin ITECS Systems NC State University --0015175cba10b92d0804c42ada81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For users who do not previously have a local profile on a client = (not using roaming profiles), I'm getting an "Integrated login fai= led:Invalid argument" error. =A0Once the user has logged in once all s= ubsequent logins work and using NIM works. Its just the initial login. But = since I'm working on student labs, that's pretty much every login.<= /div>

I enabled debugging for integrated login and a couple l= og entries back=A0KFW_AFS_get_cred has a code=3D[22] but I've not been = able to track that back through the code to figure out which call is failin= g.

Heimdal 1.5.1
NIM 2.0.102.907
OpenA= FS for Windows 1.7.15
Windows 7 Enterprise SP1, 64 bit

Billy Beaudoin
ITECS Systems
NC State= University

--0015175cba10b92d0804c42ada81-- From tjg@soe.ucsc.edu Fri Jul 6 17:20:21 2012 From: tjg@soe.ucsc.edu (Tim Gustafson) Date: Fri, 6 Jul 2012 09:20:21 -0700 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: > I just sent off a (believed to be final) patch to get 1.6.1 in the freebsd > ports collection this morning; it should hit the ports tree within a day or > two. Thanks! This has hit the ports treen and I got quite a bit further. OpenAFS is running, but now when I go to create a file system, I get: root@server: vos create server /vicepa root.afs -localauth vos : partition /vicepa does not exist on the server The folder /vicepa does indeed exist, and is empty: root@server: ls -ald /vicepa drwxr-xr-x 2 root wheel 2 Jul 6 09:09 /vicepa Is there a special flag I need to give to vos to tell it that this is a file partition, rather than an inode partition? -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From allbery.b@gmail.com Fri Jul 6 17:24:31 2012 From: allbery.b@gmail.com (Brandon Allbery) Date: Fri, 6 Jul 2012 12:24:31 -0400 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: --f46d04478babf5895304c42bb21c Content-Type: text/plain; charset=UTF-8 On Fri, Jul 6, 2012 at 12:20 PM, Tim Gustafson wrote: > > I just sent off a (believed to be final) patch to get 1.6.1 in the > freebsd > > ports collection this morning; it should hit the ports tree within a day > or > > two. > > Thanks! This has hit the ports treen and I got quite a bit further. > OpenAFS is running, but now when I go to create a file system, I get: > > root@server: vos create server /vicepa root.afs -localauth > vos : partition /vicepa does not exist on the server > > The folder /vicepa does indeed exist, and is empty: > But is it a partition (that is, a local mountpoint)? You may need to 'touch /vicepa/AlwaysAttach' to force it to use arbitrary directories; this is a bad idea in general. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms --f46d04478babf5895304c42bb21c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 6, 2012 at 12:20 PM, Tim Gustafson <tjg@soe.= ucsc.edu> wrote:
> I just sent off a (believed to be final) patch to ge= t 1.6.1 in the freebsd
> ports collection this morning; it should hit the ports tree within a d= ay or
> two.

Thanks! =C2=A0This has hit the ports treen and I got quite a bit furt= her.
OpenAFS is running, but now when I go to create a file system, I get:

root@server: vos create server /vicepa root.afs -localauth
vos : partition /vicepa does not exist on the server

The folder /vicepa does indeed exist, and is empty:
But is it a partition (that is, a local mountpoint)? =C2=A0You= may need to 'touch /vicepa/AlwaysAttach' to force it to use arbitr= ary directories; this is a bad idea in general.

--
brandon s allbery =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allbery.b@gmail.com
wandering unix systems administrato= r (available) =C2=A0 =C2=A0 (412) 475-9364 vm/sms

--f46d04478babf5895304c42bb21c-- From tjg@soe.ucsc.edu Fri Jul 6 17:26:18 2012 From: tjg@soe.ucsc.edu (Tim Gustafson) Date: Fri, 6 Jul 2012 09:26:18 -0700 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: > But is it a partition (that is, a local mountpoint)? You may need to 'touch > /vicepa/AlwaysAttach' to force it to use arbitrary directories; this is a > bad idea in general. The documentation I read was that it was acceptable to use folders, rather than mountpoints, for OpenAFS. Specifically: I'm running this OpenAFS server inside a jail right now, and the underlying file system is ZFS. Why is your suggestion a "bad idea in general"? Is it less stable? Less performant? -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From allbery.b@gmail.com Fri Jul 6 17:29:56 2012 From: allbery.b@gmail.com (Brandon Allbery) Date: Fri, 6 Jul 2012 12:29:56 -0400 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: --f46d04446ab3518adb04c42bc655 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 6, 2012 at 12:26 PM, Tim Gustafson wrote: > > But is it a partition (that is, a local mountpoint)? You may need to > 'touch > > /vicepa/AlwaysAttach' to force it to use arbitrary directories; this is a > > bad idea in general. > > Why is your suggestion a "bad idea in general"? Is it less stable? > Less performant? Less performant, harder to reason about space usage when something else can be using the space, potentially harder to recover from filesystem corruption (although you are likely pretty hosed in that case whether it's dedicated or not). -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms --f46d04446ab3518adb04c42bc655 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 6, 2012 at 12:26 PM, Tim Gustafson <tjg@soe.= ucsc.edu> wrote:
> But is it a partition (that is, a local mountpoint)?= =C2=A0You may need to 'touch
> /vicepa/AlwaysAttach' to force it to use arbitrary directories; th= is is a
> bad idea in general.

Why is your suggestion a "bad idea in general"? =C2=A0Is it= less stable?
Less performant?

Less performant, harder to= reason about space usage when something else can be using the space, poten= tially harder to recover from filesystem corruption (although you are likel= y pretty hosed in that case whether it's dedicated or not).

--
brandon s allbery =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allbery.b@gmail.com
wandering unix systems administrato= r (available) =C2=A0 =C2=A0 (412) 475-9364 vm/sms

--f46d04446ab3518adb04c42bc655-- From tjg@soe.ucsc.edu Fri Jul 6 17:32:37 2012 From: tjg@soe.ucsc.edu (Tim Gustafson) Date: Fri, 6 Jul 2012 09:32:37 -0700 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: > Less performant, harder to reason about space usage when something else can > be using the space, potentially harder to recover from filesystem corruption > (although you are likely pretty hosed in that case whether it's dedicated or > not). I can set it up as a separate ZFS file system and reserve its space, if that helps. I plan on using daily ZFS snapshots to be able to recover from file system corruption. If something goes horribly wrong, I can always shut down OpenAFS, revert to last night's snapshot, and then start it back up again. -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From adeason@sinenomine.net Fri Jul 6 17:49:51 2012 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 6 Jul 2012 11:49:51 -0500 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: <20120706114951.13cf93e4.adeason@sinenomine.net> On Fri, 6 Jul 2012 09:26:18 -0700 Tim Gustafson wrote: > The documentation I read was that it was acceptable to use folders, > rather than mountpoints, for OpenAFS. This is perfectly okay; many sites do this all the time. While there may be minor issues for performance or organization depending on your scenario, that's just a consequence of using the same disk/partition for different things; it's not openafs-specific. The only reason you have to do a little extra for non-mountpoints (the AlwaysAttach thing) is so we don't accidentally use an empty partition if something fails to mount properly. -- Andrew Deason adeason@sinenomine.net From jerrymc@msu.edu Fri Jul 6 19:38:05 2012 From: jerrymc@msu.edu (Jerry McAllister) Date: Fri, 6 Jul 2012 14:38:05 -0400 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: <20120706183805.GD15040@jerrymc.net> On Thu, Jul 05, 2012 at 10:56:19PM -0400, Benjamin Kaduk wrote: > On Wed, 27 Jun 2012, Tim Gustafson wrote: > > >>I just sent off a (believed to be final) patch to get 1.6.1 in the freebsd > >>ports collection this morning; it should hit the ports tree within a day > >>or > >>two. > >>That sharball will not work for recent versions of freebsd, as it does not > >>include the OS support for 8.3, 8-stable, 9-stable, or 10-current. > > > >Awesome; thanks. I'll just wait for the updated port then. > > Hi Tim, > > The openafs entry in the ports collection has just been updated; please > give it a shot at your convenience and report back. > > Sorry for the delay; it was longer than I expected. How about AFS client for FreeBSD 8.3? I am still stuck on that? Thanks, ////jerry > > Thanks, > > Ben > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From kaduk@MIT.EDU Fri Jul 6 19:43:17 2012 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Fri, 6 Jul 2012 14:43:17 -0400 (EDT) Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: <20120706183805.GD15040@jerrymc.net> References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> <20120706183805.GD15040@jerrymc.net> Message-ID: On Fri, 6 Jul 2012, Jerry McAllister wrote: > On Thu, Jul 05, 2012 at 10:56:19PM -0400, Benjamin Kaduk wrote: > >> On Wed, 27 Jun 2012, Tim Gustafson wrote: >> >>>> I just sent off a (believed to be final) patch to get 1.6.1 in the freebsd >>>> ports collection this morning; it should hit the ports tree within a day >>>> or >>>> two. >>>> That sharball will not work for recent versions of freebsd, as it does not >>>> include the OS support for 8.3, 8-stable, 9-stable, or 10-current. >>> >>> Awesome; thanks. I'll just wait for the updated port then. >> >> Hi Tim, >> >> The openafs entry in the ports collection has just been updated; please >> give it a shot at your convenience and report back. >> >> Sorry for the delay; it was longer than I expected. > > How about AFS client for FreeBSD 8.3? > I am still stuck on that? I believe all the patches needed for FreeBSD 8.3 are in the FreeBSD Ports tree; if you update with portsnap or csup and recompile, I'd be interested in getting feedback on whether or not things work for you. -Ben Kaduk From rmdyer@uncc.edu Fri Jul 6 20:37:23 2012 From: rmdyer@uncc.edu (Dyer, Rodney) Date: Fri, 6 Jul 2012 19:37:23 +0000 Subject: [OpenAFS] Transfer rates under OpenAFS client for Windows In-Reply-To: <5CF355D925FD4F9BA85B283AED0B4BB1@ads.iu.edu> References: <251D82B5D0E944EE900DE88C2A60DCFF@ads.iu.edu> <4FF38EBC.8010001@your-file-system.com> <18B8F39B03C7B445B4C3B97D55D4555B0B3847@RPITSEXMS2.its.uncc.edu> <5CF355D925FD4F9BA85B283AED0B4BB1@ads.iu.edu> Message-ID: <18B8F39B03C7B445B4C3B97D55D4555B0B3DE9@RPITSEXMS2.its.uncc.edu> --_000_18B8F39B03C7B445B4C3B97D55D4555B0B3DE9RPITSEXMS2itsuncc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Danko, Probably making the change to "FastSendDatagramThreshold" is what you want = to do. I've reading quite a bit about this setting, and getting conflictin= g reasoning on whether the default should be changed. For example, on this= page... http://technet.microsoft.com/fr-fr/library/cc781532%28v=3Dws.10%29.asp= x ... we see... FastSendDatagramThreshold Value Type: REG_DWORD Default: 1024 Description: Datagrams smaller than the value of this parameter go through = the fast I/O path or are buffered on send. Larger ones are held until the d= atagram is actually sent. The default value was found by testing to be the = best overall value for performance. Fast I/O means copying data and bypassi= ng the I/O subsystem, instead of mapping memory and going through the I/O s= ubsystem. This is advantageous for small amounts of data. Changing this val= ue is not generally recommended. However this page... http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_= web.aspx ... says... "Windows Server 2003 uses the FastSendDatagramThreshold registry key to det= ermine whether a datagram should go through the fast I/O path or should be = buffered during a send operation. Fast I/O means that the server bypasses t= he I/O subsystem and copies data directly to the network interface buffer. The default value of the FastSendDatagramThreshold key is 1024. If the numb= er of packets in a stream exceeds this value, additional operations are nec= essary. As a result, CPU utilization and context switches increase, while t= he maximum number of simultaneous clients that the server can handle decrea= ses. Performance tests showed that changing the default threshold setting t= o a higher value, such as 1500 bytes, improves server performance. In general, only high-bit-rate streams are affected by changing this key. P= acket sizes larger than 1024 bytes usually appear in content that has bit r= ates higher than 100 Kbps. A side effect of changing this key value is an i= ncrease in the number of non-paged pool bytes allocated for the server. Thi= s change does not cause any significant problems." I can't find any information on whether the default value of 1024 from Micr= osoft has changed under Windows 7 or Server 2008. It is generally not a good idea to change the OpenAFS client service "rxMax= MTU" value from 0 (zero) unless you have good reason to do so. In another = email to me, Jeffery Altman states "... the problem with setting RxMaxMTU (= to a specific value besides zero*) is that it disables every future thing w= e (the AFS developers*) will do to improve Rx throughput". *My emphasis. So I think the best path is to leave "rxMaxMTU" at 0 (zero), and set "FastS= endDatagramThreshold" to 1500. That shouldn't cause any of your other appl= ications problems. The setting seems to control only how much "stress" you= r CPU is under. Rodney Rodney Dyer Operations and Systems (Specialist) Mosaic Computing Group William States Lee College of Engineering University of North Carolina at Charlotte > -----Original Message----- > From: Danko Antolovic [mailto:dantolov@indiana.edu] > Sent: Thursday, July 05, 2012 5:26 PM > To: Dyer, Rodney; openafs-info@openafs.org > Subject: RE: [OpenAFS] Transfer rates under OpenAFS client for Windows > > The parameter RxMaxMTU makes a difference: when it is set to 1024, using = Intel > 82567LM NIC, network utilization is close to 100% for both reads and writ= es with > Windows AFS client. Thanks for the germane information, Rodney. > > > My system configuration: Dell Latitude, 2.53 GHz, 32-bit, 3.45 GByte RAM, > 100 mbit/s Ethernet port, Intel 82567LM Gigabit NIC. > > Windows XP, paging file size is 5302 MBytes, although that is probably no= t > critical. > > Open AFS client version 1.7.1500. > > This set of AFS client configuration parameters works reasonably well on = my > system: > > Key Name: > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaem > on\Param > eters > Class Name: > Last Write Time: 7/5/2012 - 4:17 PM > Value 0 > Name: HideDotFiles > Type: REG_DWORD > Data: 0x1 > > Value 1 > Name: > Type: REG_SZ > Data: > > Value 2 > Name: IsGateway > Type: REG_DWORD > Data: 0x0 > > Value 3 > Name: RxMaxMTU > Type: REG_DWORD > Data: 0x400 > > Value 4 > Name: NetbiosName > Type: REG_SZ > Data: AFS > > Value 5 > Name: Cell > Type: REG_SZ > Data: iu.edu > > Value 6 > Name: MountRoot > Type: REG_SZ > Data: /afs > > Value 7 > Name: NoFindLanaByName > Type: REG_DWORD > Data: 0x1 > > Value 8 > Name: FreelanceClient > Type: REG_DWORD > Data: 0x1 > > Value 9 > Name: UseDNS > Type: REG_DWORD > Data: 0x1 > > Value 10 > Name: SecurityLevel > Type: REG_DWORD > Data: 0x1 > > Value 11 > Name: SMBAuthType > Type: REG_DWORD > Data: 0x2 > > Value 12 > Name: CacheSize > Type: REG_DWORD > Data: 0xc3500 > > Value 13 > Name: ChunkSize > Type: REG_DWORD > Data: 0x15 > > Value 14 > Name: ServerThreads > Type: REG_DWORD > Data: 0x28 > > Value 15 > Name: Daemons > Type: REG_DWORD > Data: 0x10 > > Value 16 > Name: Stats > Type: REG_DWORD > Data: 0x4e20 > > > > > > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info- > admin@openafs.org] > On Behalf Of Dyer, Rodney > Sent: Tuesday, July 03, 2012 9:40 PM > To: jaltman@your-file-system.com; openafs-info@openafs.org > Subject: RE: [OpenAFS] Transfer rates under OpenAFS client for Windows > > I'm not sure if this information still applies here, but back in 2010 I d= id some testing > and found that some of our DELL client machines with Intel based "on boar= d" > network chips performed significantly slower on writes than reads. We we= re using > Windows XP Pro SP3 (32bit). The OpenAFS client was the 1.5 series at the= time. > > After more research I found that changing the rxMaxMTU to a value of 512 = to > 1024 on our network increased the write speed up to 150 percent. > > If I set the value rxMaxMTU from 1024 to 1025, the performance of the cli= ent > dropped by at least half. > > The poor performance only seems to appear on two models of Dell clients..= . > > Dell OptiPlex 760, with "Intel(R) 82567LM-3 Gigabit Network Connection" > Dell OptiPlex 755, with "Intel(R) 82566DM-2 Gigabit Network Connection" > > All other Dell machines that I've tested with the "Broadcom NetXtreme 57x= x Gigabit > Controller" were ok with either 0 (zero), or 1260 set as "rxMaxMTU". > > This was tested in multiple offices on multiple machines. > > Normally the AFS client automatically determines the MaxMTU if the rxMaxM= TU is > set to 0. > > The issue was not really with the OpenAFS client, it was with how the Int= el network > driver was interacting with Windows. > > There was more research done and found that changing the Windows > "FastSendDatagramThreshold" to something like 1500 solved the problem. > However I was never sure if I wanted to change the Microsoft "default" on= all our > machines. > > We never implemented a mass roll-out network configuration change to our > Windows client machines to fix the problem. I just quietly let the probl= em drop on > the floor. So the problem still exists in our environment. > > Rodney Dyer > > > > -----Original Message----- > > From: openafs-info-admin@openafs.org > [mailto:openafs-info-admin@openafs.org] On > > Behalf Of Jeffrey Altman > > Sent: Tuesday, July 03, 2012 8:31 PM > > To: openafs-info@openafs.org > > Subject: Re: [OpenAFS] Transfer rates under OpenAFS client for Windows > > > > On 7/3/2012 4:27 PM, Danko Antolovic wrote: > > > > > My first question is why copying from the client to the file server > > > is so much slower (by a factor of 2 or 3) than the other way > > > around. The other question is why the network utilization, at least > > > as reported under Windows, never approaches the line rate, even at > > > quiet times, but rather stays below the caps of 70 and 30 percent. > > > > It won't go any faster with the OpenAFS RX implementation. > > > > Jeffrey Altman > > :?? --_000_18B8F39B03C7B445B4C3B97D55D4555B0B3DE9RPITSEXMS2itsuncc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Danko,

 

Probably making the change to "FastSendDatag= ramThreshold" is what you want to do.  I've reading quite a bit a= bout this setting, and getting conflicting reasoning on whether the default= should be changed.  For example, on this page...

 

     http://technet.microsoft.com/fr-fr/library/cc781532%28v=3Dws.10%29.aspx=

 

... we see...

 

FastSendDatagramThr= eshold

 

Value Type: REG= _DWORD

 

Default: 1024

 

Description: Da= tagrams smaller than the value of this parameter go through the fast I/O pa= th or are buffered on send. Larger ones are held until the datagram is actu= ally sent. The default value was found by testing to be the best overall value for performance. Fast I/O means co= pying data and bypassing the I/O subsystem, instead of mapping memory and g= oing through the I/O subsystem. This is advantageous for small amounts of d= ata. Changing this value is not generally recommended.<= /p>

 

 

However this page...

 

     http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.a= spx

 

... says...

 

"Windows Serve= r 2003 uses the FastSendDatagramThreshold registry key to determine whether= a datagram should go through the fast I/O path or should be buffered durin= g a send operation. Fast I/O means that the server bypasses the I/O subsystem and copies data directly to the network = interface buffer.

 

The default value o= f the FastSendDatagramThreshold key is 1024. If the number of packets in a = stream exceeds this value, additional operations are necessary. As a result= , CPU utilization and context switches increase, while the maximum number of simultaneous clients that the server= can handle decreases. Performance tests showed that changing the default t= hreshold setting to a higher value, such as 1500 bytes, improves server per= formance.

 

In general, only= high-bit-rate streams are affected by changing this key. Packet sizes larg= er than 1024 bytes usually appear in content that has bit rates higher than= 100 Kbps. A side effect of changing this key value is an increase in the number of non-paged pool bytes alloca= ted for the server. This change does not cause any significant problems= ."

 

 

I can't find any information on whether the defau= lt value of 1024 from Microsoft has changed under Windows 7 or Server 2008.=

 

It is generally not a good idea to change the Ope= nAFS client service "rxMaxMTU" value from 0 (zero) unless you hav= e good reason to do so.  In another email to me, Jeffery Altman states= "... the problem with setting RxMaxMTU (to a specific value besides zero*) is that it disables every future= thing we (the AFS developers= *) will do to improve Rx throughput".  *My emphasis.

 

So I think the best path is to leave “rxMax= MTU” at 0 (zero), and set “FastSendDatagramThreshold” to = 1500.  That shouldn’t cause any of your other applications probl= ems.  The setting seems to control only how much “stress” = your CPU is under.

 

Rodney

 

Rodney Dyer

Operations and Systems (Specialist)

Mosaic Computing Group

William States Lee College of Engineering=

University of North Carolina at Charlotte=

 

 

> -----Original Message-----

> From: Danko Antolovic [mailto:dantolov@india= na.edu]

> Sent: Thursday, July 05, 2012 5:26 PM

> To: Dyer, Rodney; openafs-info@openafs.org

> Subject: RE: [OpenAFS] Transfer rates under = OpenAFS client for Windows

>

> The parameter RxMaxMTU makes a difference: w= hen it is set to 1024, using Intel

> 82567LM NIC, network utilization is close to= 100% for both reads and writes with

> Windows AFS client. Thanks for the germane i= nformation, Rodney.

>

>

> My system configuration: Dell Latitude, 2.53= GHz, 32-bit, 3.45 GByte RAM,

> 100 mbit/s Ethernet port, Intel 82567LM Giga= bit NIC.

>

> Windows XP, paging file size is 5302 MBytes,= although that is probably not

> critical.

>

> Open AFS client version 1.7.1500.=

>

> This set of AFS client configuration paramet= ers works reasonably well on my

> system:

>

> Key Name:

> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\= Services\TransarcAFSDaem

> on\Param

> eters

> Class Name:     &nb= sp;  <NO CLASS>

> Last Write Time:   7/5/2012 - 4:17= PM

> Value 0

>   Name:    &nb= sp;       HideDotFiles

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x1

>

> Value 1

>   Name:    &nb= sp;       <NO NAME>

>   Type:    &nb= sp;       REG_SZ

>   Data:

>

> Value 2

>   Name:    &nb= sp;       IsGateway

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x0

>

> Value 3

>   Name:    &nb= sp;       RxMaxMTU

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x400

>

> Value 4

>   Name:    &nb= sp;       NetbiosName

>   Type:    &nb= sp;       REG_SZ

>   Data:    &nb= sp;       AFS

>

> Value 5

>   Name:    &nb= sp;       Cell

>   Type:    &nb= sp;       REG_SZ

>   Data:    &nb= sp;       iu.edu

>

> Value 6

>   Name:    &nb= sp;       MountRoot

>   Type:    &nb= sp;       REG_SZ

>   Data:    &nb= sp;       /afs

>

> Value 7

>   Name:    &nb= sp;       NoFindLanaByName

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x1

>

> Value 8

>   Name:    &nb= sp;       FreelanceClient

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x1

>

> Value 9

>   Name:    &nb= sp;       UseDNS

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x1

>

> Value 10

>   Name:    &nb= sp;       SecurityLevel

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x1

>

> Value 11

>   Name:    &nb= sp;       SMBAuthType

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x2

>

> Value 12

>   Name:    &nb= sp;       CacheSize

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0xc3500

>

> Value 13

>   Name:    &nb= sp;       ChunkSize

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x15

>

> Value 14

>   Name:    &nb= sp;       ServerThreads

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x28

>

> Value 15

>   Name:    &nb= sp;       Daemons

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x10

>

> Value 16

>   Name:    &nb= sp;       Stats

>   Type:    &nb= sp;       REG_DWORD

>   Data:    &nb= sp;       0x4e20

>

>

>

>

>

> -----Original Message-----

> From: openafs-info-admin@openafs.org [mailto= :openafs-info-

> admin@openafs.org]

> On Behalf Of Dyer, Rodney

> Sent: Tuesday, July 03, 2012 9:40 PM

> To: jaltman@your-file-system.com; openafs-in= fo@openafs.org

> Subject: RE: [OpenAFS] Transfer rates under = OpenAFS client for Windows

>

> I'm not sure if this information still appli= es here, but back in 2010 I did some testing

> and found that some of our DELL client machi= nes with Intel based "on board"

> network chips performed significantly slower= on writes than reads.  We were using

> Windows XP Pro SP3 (32bit).  The OpenAF= S client was the 1.5 series at the time.

>

> After more research I found that changing th= e rxMaxMTU to a value of 512 to

> 1024 on our network increased the write spee= d up to 150 percent.

>

> If I set the value rxMaxMTU from 1024 to 102= 5, the performance of the client

> dropped by at least half.

>

> The poor performance only seems to appear on= two models of Dell clients...

>

> Dell OptiPlex 760, with "Intel(R) 82567= LM-3 Gigabit Network Connection"

> Dell OptiPlex 755, with "Intel(R) 82566= DM-2 Gigabit Network Connection"

>

> All other Dell machines that I've tested wit= h the "Broadcom NetXtreme 57xx Gigabit

> Controller" were ok with either 0 (zero= ), or 1260 set as "rxMaxMTU".

>

> This was tested in multiple offices on multi= ple machines.

>

> Normally the AFS client automatically determ= ines the MaxMTU if the rxMaxMTU is

> set to 0.

>

> The issue was not really with the OpenAFS cl= ient, it was with how the Intel network

> driver was interacting with Windows.

>

> There was more research done and found that = changing the Windows

> "FastSendDatagramThreshold" to som= ething like 1500 solved the problem.

> However I was never sure if I wanted to chan= ge the Microsoft "default" on all our

> machines.

>

> We never implemented a mass roll-out network= configuration change to our

> Windows client machines to fix the problem.&= nbsp; I just quietly let the problem drop on

> the floor.  So the problem still exists= in our environment.

>

> Rodney Dyer

>

>

> > -----Original Message-----

> > From: openafs-info-admin@openafs.org

> [mailto:openafs-info-admin@openafs.org] On

> > Behalf Of Jeffrey Altman

> > Sent: Tuesday, July 03, 2012 8:31 PM

> > To: openafs-info@openafs.org=

> > Subject: Re: [OpenAFS] Transfer rates u= nder OpenAFS client for Windows

> >

> > On 7/3/2012 4:27 PM, Danko Antolovic wr= ote:

> >

> > > My first question is why copying f= rom the client to the file server

> > > is so much slower (by a factor of&= nbsp; 2 or 3) than the other way

> > > around. The other question is why = the network utilization, at least

> > > as reported under Windows, never a= pproaches the line rate, even at

> > > quiet times, but rather stays belo= w the caps of 70 and 30 percent.

> >

> > It won't go any faster with the OpenAFS= RX implementation.

> >

> > Jeffrey Altman

>

> :??

 

--_000_18B8F39B03C7B445B4C3B97D55D4555B0B3DE9RPITSEXMS2itsuncc_-- From sebby@anl.gov Fri Jul 6 20:56:53 2012 From: sebby@anl.gov (Brian Sebby) Date: Fri, 6 Jul 2012 14:56:53 -0500 Subject: [OpenAFS] token lifetime In-Reply-To: References: <1058035206.28454.8.camel@rich.habitat.thewallacepack.net> <28723e2d748c4dbdb136f6aa2b1a0362@INFPWXH002.ad.unsw.edu.au> Message-ID: <20120706195653.GA2652@atalanta.it.anl.gov> The lifetime of a Kerberos ticket is a security measure to prevent someone from being able to use your credentials if they can crack your ticket/token. AFS still uses DES for its tokens, which is incredibly easy to crack these days. The limited lifetime is part of what prevents this from being an incredibly large security issue. If you have lifetimes that long, with DES, you might as well just run your servers with -noauth to turn off all authentication. (Please please please do not actually do this.) If you want long-lived tickets, look into using kinit -r, k5start, or any of the other tools for extending the lifetime of a ticket/token. Brian On Fri, Jul 06, 2012 at 06:44:46PM +1000, Jayen Ashar wrote: > On Fri, Jul 6, 2012 at 6:08 PM, Jeffrey Altman > wrote: > > The code in question is tkt_DecodeTicket5() in src/rxkad/ticket5.c and > > tkt_CheckTimes() in src/rxkad/ticket.c. If the 'end' value is not > > exactly NEVERDATE (0xFFFFFFFF) and ('end' - 'start' is greater than > > 30 days, the token will be rejected. > > Can I do anything (without changing code) to make the end 0xFFFFFFFF? > As far as I can set, the end is only 0x7FFFFFFF. If not, is it > reasonable to change the 'end' - 'start' to 180 days? > > Thanks, > Jayen > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Brian Sebby (sebby@anl.gov) | Infrastructure and Operation Services Phone: +1 630.252.9935 | Computing and Information Systems Fax: +1 630.252.4601 | Argonne National Laboratory From dantolov@indiana.edu Fri Jul 6 22:30:26 2012 From: dantolov@indiana.edu (Danko Antolovic) Date: Fri, 06 Jul 2012 17:30:26 -0400 Subject: [OpenAFS] Transfer rates under OpenAFS client for Windows In-Reply-To: <18B8F39B03C7B445B4C3B97D55D4555B0B3DE9@RPITSEXMS2.its.uncc.edu> References: <251D82B5D0E944EE900DE88C2A60DCFF@ads.iu.edu> <4FF38EBC.8010001@your-file-system.com> <18B8F39B03C7B445B4C3B97D55D4555B0B3847@RPITSEXMS2.its.uncc.edu> <5CF355D925FD4F9BA85B283AED0B4BB1@ads.iu.edu> <18B8F39B03C7B445B4C3B97D55D4555B0B3DE9@RPITSEXMS2.its.uncc.edu> Message-ID: <4FF758F2.9010801@indiana.edu> Brian, thanks, I have seen the same/similar descriptions. The crux of it seems to be that rxMaxMTU (packet size) must be no larger than FastSendDatagramThreshold, else the UDP packet is sent to the "slow" route by Windows. Keeping rxMaxMTU at 1024, or increasing FastSendDatagramThreshold above its default of 1024, has more or less the same effect on network utilization. If you gain any detailed insight into the "slow" vs. "fast" mechanism, I'd like to hear about it. CPU load is indeed a bit higher in the fast mode, as you pointed out. Policywise, leaving parameters undefined comes down to trusting either the OpenAFS community or Microsoft to do the right things in the future. Granted, MS charges for its services, but my expectations regarding these two bodies are otherwise fairly similar. Regards, Danko On 07/06/2012 03:37 PM, Dyer, Rodney wrote: > > Danko, > > Probably making the change to "FastSendDatagramThreshold" is what you > want to do. I've reading quite a bit about this setting, and getting > conflicting reasoning on whether the default should be changed. For > example, on this page... > > http://technet.microsoft.com/fr-fr/library/cc781532%28v=ws.10%29.aspx > > ... we see... > > *FastSendDatagramThreshold* > > // > > *Value Type*: REG_DWORD > > // > > *Default*: 1024 > > // > > *Description*: Datagrams smaller than the value of this parameter go > through the fast I/O path or are buffered on send. Larger ones are > held until the datagram is actually sent. The default value was found > by testing to be the best overall value for performance. Fast I/O > means copying data and bypassing the I/O subsystem, instead of mapping > memory and going through the I/O subsystem. This is advantageous for > small amounts of data. *Changing this value is not generally > recommended*.// > > However this page... > > http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.aspx > > ... says... > > /"Windows Server 2003 uses the FastSendDatagramThreshold registry key > to determine whether a datagram should go through the fast I/O path or > should be buffered during a send operation. Fast I/O means that the > server bypasses the I/O subsystem and copies data directly to the > network interface buffer./ > > // > > /The default value of the FastSendDatagramThreshold key is 1024. If > the number of packets in a stream exceeds this value, additional > operations are necessary. As a result, CPU utilization and context > switches increase, while the maximum number of simultaneous clients > that the server can handle decreases. Performance tests showed that > changing the default threshold setting to a higher value, such as 1500 > bytes, improves server performance. / > > // > > */In general, only high-bit-rate streams are affected by changing this > key. Packet sizes larger than 1024 bytes usually appear in content > that has bit rates higher than 100 Kbps. A side effect of changing > this key value is an increase in the number of non-paged pool bytes > allocated for the server. This change does not cause any significant > problems/*/."/ > > I can't find any information on whether the default value of 1024 from > Microsoft has changed under Windows 7 or Server 2008. > > It is generally not a good idea to change the OpenAFS client service > "rxMaxMTU" value from 0 (zero) unless you have good reason to do so. > In another email to me, Jeffery Altman states "/... the problem with > setting RxMaxMTU (/to a specific value besides zero/*) is that it > disables every future thing we (/the AFS developers/*) will do to > improve Rx throughput/". *My emphasis. > > So I think the best path is to leave “rxMaxMTU” at 0 (zero), and set > “FastSendDatagramThreshold” to 1500. That shouldn’t cause any of your > other applications problems. The setting seems to control only how > much “stress” your CPU is under. > > Rodney > > Rodney Dyer > > Operations and Systems (Specialist) > > Mosaic Computing Group > > William States Lee College of Engineering > > University of North Carolina at Charlotte > > From tjg@soe.ucsc.edu Fri Jul 6 22:44:27 2012 From: tjg@soe.ucsc.edu (Tim Gustafson) Date: Fri, 6 Jul 2012 14:44:27 -0700 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: > You may need to 'touch /vicepa/AlwaysAttach' to force it to use arbitrary > directories So, I've done this now, but I still get the same error: root@server: touch /vicepa/AlwaysAttach root@server: vos create server /vicepa root.afs -localauth vos : partition /vicepa does not exist on the server -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From tjg@soe.ucsc.edu Fri Jul 6 22:46:24 2012 From: tjg@soe.ucsc.edu (Tim Gustafson) Date: Fri, 6 Jul 2012 14:46:24 -0700 Subject: [OpenAFS] Re: Setting Up OpenAFS on FreeBSD In-Reply-To: References: <20120626123924.67a4c7e0.adeason@sinenomine.net> <20120626164710.7d6faabc.adeason@sinenomine.net> <20120627121726.d272c1cd.adeason@sinenomine.net> Message-ID: > So, I've done this now, but I still get the same error: Doh! Scratch that! I needed to re-start the OpenAFS server for it to realize the "patrition" was there. -- Tim Gustafson tjg@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A From jayen@science.unsw.edu.au Sat Jul 7 03:43:20 2012 From: jayen@science.unsw.edu.au (Jayen Ashar) Date: Sat, 7 Jul 2012 12:43:20 +1000 Subject: [OpenAFS] token lifetime In-Reply-To: <4FF7A1B0.9090702@gmail.com> References: <1058035206.28454.8.camel@rich.habitat.thewallacepack.net> <28723e2d748c4dbdb136f6aa2b1a0362@INFPWXH002.ad.unsw.edu.au> <4FF7A1B0.9090702@gmail.com> Message-ID: We have looked into the other tools, and: - with renewable tickets, is any security gained? a cracked/stolen ticket can be renewed until the renewable lifetime, which seems not much different to me than simply changing the expiration time. - with keytabs, what if the keytab is unknowingly cracked or stolen? we have some long-running processes, which we would like to be able to read/write to afs beyond 30 days. some of these jobs may run on clients we don't control, so we prefer to make changes server-side. we are looking at options that offer convenience over security. we don't want a user to come after us after six months saying he/she has to redo an experiment because his token expired. why 30 days? does it take 30 days to crack DES? is there much difference between 30 days and 300 days? we're less concerned about the ticket/token being cracked and more concerned about it being stolen. while i agree the lifetime limits the use of a stolen ticket, if a ticket can be unknowingly stolen once, it can probably be stolen repeatedly. Thanks, Jayen On 07/07/12 05:56, Brian Sebby wrote: > The lifetime of a Kerberos ticket is a security measure to prevent someone > from being able to use your credentials if they can crack your ticket/token. > AFS still uses DES for its tokens, which is incredibly easy to crack these > days. The limited lifetime is part of what prevents this from being an > incredibly large security issue. If you have lifetimes that long, with DES, > you might as well just run your servers with -noauth to turn off all > authentication. (Please please please do not actually do this.) > > If you want long-lived tickets, look into using kinit -r, k5start, or any > of the other tools for extending the lifetime of a ticket/token. > > > Brian > > On Fri, Jul 06, 2012 at 06:44:46PM +1000, Jayen Ashar wrote: >> On Fri, Jul 6, 2012 at 6:08 PM, Jeffrey Altman >> wrote: >>> The code in question is tkt_DecodeTicket5() in src/rxkad/ticket5.c and >>> tkt_CheckTimes() in src/rxkad/ticket.c. If the 'end' value is not >>> exactly NEVERDATE (0xFFFFFFFF) and ('end' - 'start' is greater than >>> 30 days, the token will be rejected. >> >> Can I do anything (without changing code) to make the end 0xFFFFFFFF? >> As far as I can set, the end is only 0x7FFFFFFF. If not, is it >> reasonable to change the 'end' - 'start' to 180 days? >> >> Thanks, >> Jayen From jaltman@secure-endpoints.com Sat Jul 7 05:18:34 2012 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Sat, 07 Jul 2012 00:18:34 -0400 Subject: [OpenAFS] token lifetime In-Reply-To: References: <1058035206.28454.8.camel@rich.habitat.thewallacepack.net> <28723e2d748c4dbdb136f6aa2b1a0362@INFPWXH002.ad.unsw.edu.au> <4FF7A1B0.9090702@gmail.com> Message-ID: <4FF7B89A.2020603@secure-endpoints.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0417F8BB2CDB35A5CA2D0236 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable By requiring ticket renewal, if the ticket is stolen you can prevent its renewal at the KDC. Renewal will also appear in the KDC logs so you will know where it is being used from. In 1998 it took 45 days to brute force a DES key. 14 years later it probably takes under a day. On Friday, July 06, 2012 10:43:20 PM, Jayen Ashar wrote: > We have looked into the other tools, and: > > - with renewable tickets, is any security gained? a cracked/stolen > ticket can be renewed until the renewable lifetime, which seems not muc= h > different to me than simply changing the expiration time. > > - with keytabs, what if the keytab is unknowingly cracked or stolen? > > we have some long-running processes, which we would like to be able to > read/write to afs beyond 30 days. some of these jobs may run on client= s > we don't control, so we prefer to make changes server-side. we are > looking at options that offer convenience over security. we don't want= > a user to come after us after six months saying he/she has to redo an > experiment because his token expired. > > why 30 days? does it take 30 days to crack DES? is there much > difference between 30 days and 300 days? > > we're less concerned about the ticket/token being cracked and more > concerned about it being stolen. while i agree the lifetime limits the= > use of a stolen ticket, if a ticket can be unknowingly stolen once, it > can probably be stolen repeatedly. > > Thanks, > Jayen > > On 07/07/12 05:56, Brian Sebby wrote: >> The lifetime of a Kerberos ticket is a security measure to prevent som= eone >> from being able to use your credentials if they can crack your ticket/= token. >> AFS still uses DES for its tokens, which is incredibly easy to crack t= hese >> days. The limited lifetime is part of what prevents this from being a= n >> incredibly large security issue. If you have lifetimes that long, wit= h DES, >> you might as well just run your servers with -noauth to turn off all >> authentication. (Please please please do not actually do this.) >> >> If you want long-lived tickets, look into using kinit -r, k5start, or = any >> of the other tools for extending the lifetime of a ticket/token. >> >> >> Brian >> >> On Fri, Jul 06, 2012 at 06:44:46PM +1000, Jayen Ashar wrote: >>> On Fri, Jul 6, 2012 at 6:08 PM, Jeffrey Altman >>> wrote: >>>> The code in question is tkt_DecodeTicket5() in src/rxkad/ticket5.c a= nd >>>> tkt_CheckTimes() in src/rxkad/ticket.c. If the 'end' value is not= >>>> exactly NEVERDATE (0xFFFFFFFF) and ('end' - 'start' is greater than >>>> 30 days, the token will be rejected. >>> >>> Can I do anything (without changing code) to make the end 0xFFFFFFFF?= >>> As far as I can set, the end is only 0x7FFFFFFF. If not, is it >>> reasonable to change the 'end' - 'start' to 180 days? >>> >>> Thanks, >>> Jayen > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --------------enig0417F8BB2CDB35A5CA2D0236 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJP97ieAAoJENxm1CNJffh4I18H/1HppqVnmLIO0IR/JoCLGGtA /jEyhz/i9Ad3LvwggkHu56lOsayrT2/dtqtaMsD9XeqOz8vNJKUdzsrYSkgCmmJ3 jEczOeek2uiiGc6fu0S0xruHYc7xy5AH29SuCspAG+SG1faVcwrEibwPE8xVmFiv eC2AVDVRU7YiAGqNl5N6GuwGwuGs8lUWB5iI/vSL7h6DIFkwR1f8t3SaOQH6ZFJv /guTFwa2rF9m+360zUxnLXbC3fWeBSXARiLcpjJIi3foMhLIf2v+UPDhaurUfC0G HOxBDHU3UiixMg+XN4IzQyRILipOWTwBS+ZUv4M6IWszL92sp1sctZSDz4g0lvs= =apO0 -----END PGP SIGNATURE----- --------------enig0417F8BB2CDB35A5CA2D0236-- From LEWIS@NKI.RFMH.ORG Thu Jul 12 02:25:28 2012 From: LEWIS@NKI.RFMH.ORG (Lewis, Dave) Date: Wed, 11 Jul 2012 21:25:28 -0400 Subject: [OpenAFS] empty /afs Message-ID: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> Hi, On one of our fileservers, /afs is empty. (We're running the AFS client on the fileserver because I sometimes do client operations there.) All of our other servers and clients seem fine. I looked through the AFS log files and didn't see anything obvious (but I could have missed something). The /usr/vice/cache partition is ext3. CentOS 5.6, OpenAFS 1.4.14.1, 64-bit $ ls -la /afs total 8 drwxr-xr-x 2 root root 4096 Apr 14 2010 ./ drwxr-xr-x 34 root root 4096 May 26 19:16 ../ # service openafs-client status afsd (pid 4320) is running... # du -sh /usr/vice/cache 24M /usr/vice/cache # cat /usr/vice/etc/cacheinfo /afs:/usr/vice/cache:900000 $ cat /etc/sysconfig/openafs # OpenAFS Client Configuration AFSD_ARGS=3D"-fakestat -stat 4000 -dcache 4000 -daemons 6 -volumes 256 -files 50000 -nosettime" # OpenAFS Server Configuration BOSSERVER_ARGS=3D On another server (set up the same way): $ ls -la /afs total 15 drwxrwxrwx 2 root root 2048 May 17 2000 ./ drwxr-xr-x 33 root root 4096 May 26 19:20 ../ lrwxr-xr-x 1 bin root 13 May 17 2000 cabi -> cabi.rfmh.org/ drwxrwxrwx 2 root root 2048 Jun 14 2011 .cabi.rfmh.org/ drwxrwxrwx 2 root root 2048 Jun 14 2011 cabi.rfmh.org/ # du -sh /usr/vice/cache 827M /usr/vice/cache Would it be safe to restart the AFS client and see if it fixes the problem? Since the computer is a server and I haven't figured out the cause of the problem, I thought I would ask here first. Thanks, Dave =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 David P. Lewis=20 Center for Advanced Brain Imaging, Division of Medical Physics=20 The Nathan S. Kline Institute for Psychiatric Research=20 140 Old Orangeburg Road, Orangeburg, NY 10962=20 Conserve Resources. Print only when necessary. IMPORTANT NOTICE: This e-mail is meant only for the use of the intended r= ecipient. It may contain confidential information which is legally privil= egedor otherwise protected by law. If you received this e-mail in error o= r from someone who is not authorized to send it to you, you are strictly = prohibited from reviewing, using, disseminating, distributing or copying = the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AN= D DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation. From shadow@gmail.com Thu Jul 12 02:33:18 2012 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 11 Jul 2012 21:33:18 -0400 Subject: [OpenAFS] empty /afs In-Reply-To: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> Message-ID: On Wed, Jul 11, 2012 at 9:25 PM, Lewis, Dave wrote: > Hi, > > On one of our fileservers, /afs is empty. (We're running the AFS client > on the fileserver because I sometimes do client operations there.) All > of our other servers and clients seem fine. > > I looked through the AFS log files and didn't see anything obvious (but > I could have missed something). The /usr/vice/cache partition is ext3. > > CentOS 5.6, OpenAFS 1.4.14.1, 64-bit > > $ ls -la /afs > total 8 > drwxr-xr-x 2 root root 4096 Apr 14 2010 ./ > drwxr-xr-x 34 root root 4096 May 26 19:16 ../ > > # service openafs-client status > afsd (pid 4320) is running... > > # du -sh /usr/vice/cache > 24M /usr/vice/cache > > # cat /usr/vice/etc/cacheinfo > /afs:/usr/vice/cache:900000 > > $ cat /etc/sysconfig/openafs > # OpenAFS Client Configuration > AFSD_ARGS="-fakestat -stat 4000 -dcache 4000 -daemons 6 -volumes 256 > -files 50000 -nosettime" ...but not dynroot. anyway, did this server perhaps have the afs client start before root.afs was available? > Would it be safe to restart the AFS client and see if it fixes the > problem? Since the computer is a server and I haven't figured out the > cause of the problem, I thought I would ask here first. it might panic. there's an unfortunate issue where the client will probably now not shut down cleanly. if it doesn't, do not restart the client or the host will crash. i suggest either using dynroot or scripting to make sure the fileserver is up before the client starts. -- Derrick From drh@umich.edu Thu Jul 12 02:44:05 2012 From: drh@umich.edu (Dan Hyde) Date: Wed, 11 Jul 2012 21:44:05 -0400 Subject: [OpenAFS] empty /afs In-Reply-To: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> Message-ID: There be dragons. We learned the had way a long time ago that it is possible= to have your server require you have a working client before the server wou= ld start (before it had access to what the client could provide). Please re= consider. On Jul 11, 2012, at 9:25 PM, "Lewis, Dave" wrote: > Hi, >=20 > On one of our fileservers, /afs is empty. (We're running the AFS client > on the fileserver because I sometimes do client operations there.) All > of our other servers and clients seem fine. >=20 > I looked through the AFS log files and didn't see anything obvious (but > I could have missed something). The /usr/vice/cache partition is ext3. >=20 > CentOS 5.6, OpenAFS 1.4.14.1, 64-bit >=20 > $ ls -la /afs > total 8 > drwxr-xr-x 2 root root 4096 Apr 14 2010 ./ > drwxr-xr-x 34 root root 4096 May 26 19:16 ../ >=20 > # service openafs-client status > afsd (pid 4320) is running... >=20 > # du -sh /usr/vice/cache > 24M /usr/vice/cache >=20 > # cat /usr/vice/etc/cacheinfo > /afs:/usr/vice/cache:900000 >=20 > $ cat /etc/sysconfig/openafs > # OpenAFS Client Configuration > AFSD_ARGS=3D"-fakestat -stat 4000 -dcache 4000 -daemons 6 -volumes 256 > -files 50000 -nosettime" >=20 > # OpenAFS Server Configuration > BOSSERVER_ARGS=3D >=20 >=20 > On another server (set up the same way): >=20 > $ ls -la /afs > total 15 > drwxrwxrwx 2 root root 2048 May 17 2000 ./ > drwxr-xr-x 33 root root 4096 May 26 19:20 ../ > lrwxr-xr-x 1 bin root 13 May 17 2000 cabi -> cabi.rfmh.org/ > drwxrwxrwx 2 root root 2048 Jun 14 2011 .cabi.rfmh.org/ > drwxrwxrwx 2 root root 2048 Jun 14 2011 cabi.rfmh.org/ >=20 > # du -sh /usr/vice/cache > 827M /usr/vice/cache >=20 > Would it be safe to restart the AFS client and see if it fixes the > problem? Since the computer is a server and I haven't figured out the > cause of the problem, I thought I would ask here first. >=20 > Thanks, > Dave >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > David P. Lewis=20 > Center for Advanced Brain Imaging, Division of Medical Physics=20 > The Nathan S. Kline Institute for Psychiatric Research=20 > 140 Old Orangeburg Road, Orangeburg, NY 10962=20 >=20 >=20 >=20 >=20 >=20 > Conserve Resources. Print only when necessary. >=20 > IMPORTANT NOTICE: This e-mail is meant only for the use of the intended re= cipient. It may contain confidential information which is legally privileged= or otherwise protected by law. If you received this e-mail in error or from s= omeone who is not authorized to send it to you, you are strictly prohibited f= rom reviewing, using, disseminating, distributing or copying the e-mail. PLE= ASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS MESS= AGE FROM YOUR SYSTEM. Thank you for your cooperation. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >=20 >=20 From LEWIS@NKI.RFMH.ORG Thu Jul 12 03:40:08 2012 From: LEWIS@NKI.RFMH.ORG (Lewis, Dave) Date: Wed, 11 Jul 2012 22:40:08 -0400 Subject: [OpenAFS] empty /afs In-Reply-To: References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> Message-ID: <2586A1048152BE4D861E64A98700AD420B1EFAF7@nki-mail.NKI.rfmh.org> > -----Original Message----- > From: Derrick Brashear [mailto:shadow@gmail.com] > Sent: Wednesday, July 11, 2012 9:33 PM > To: Lewis, Dave > Cc: openafs-info@openafs.org > Subject: Re: [OpenAFS] empty /afs >=20 [...] > > $ cat /etc/sysconfig/openafs > > # OpenAFS Client Configuration > > AFSD_ARGS=3D"-fakestat -stat 4000 -dcache 4000 -daemons 6 -volumes 25= 6 > > -files 50000 -nosettime" >=20 > ...but not dynroot. >=20 > anyway, did this server perhaps have the afs client start before > root.afs was available? Maybe, oops. It didn't occur to me that that might happen, since the server has root.afs. The afs server is set to start before the client (S49openafs-server vs. S50openafs-client). But maybe there was some kind of delay and root.afs wasn't yet available when the afs client needed it. The last reboot was soon after a power failure. > > Would it be safe to restart the AFS client and see if it fixes the > > problem? Since the computer is a server and I haven't figured out > the > > cause of the problem, I thought I would ask here first. >=20 > it might panic. there's an unfortunate issue where the client will > probably now not shut down cleanly. > if it doesn't, do not restart the client or the host will crash. I'm glad I asked! > i suggest either using dynroot or scripting to make sure the > fileserver is up before the client starts. >=20 > -- > Derrick Thanks, I'll take care of it later, when I'm not tired. Conserve Resources. Print only when necessary. IMPORTANT NOTICE: This e-mail is meant only for the use of the intended r= ecipient. It may contain confidential information which is legally privil= egedor otherwise protected by law. If you received this e-mail in error o= r from someone who is not authorized to send it to you, you are strictly = prohibited from reviewing, using, disseminating, distributing or copying = the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AN= D DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation. From LEWIS@NKI.RFMH.ORG Thu Jul 12 03:45:05 2012 From: LEWIS@NKI.RFMH.ORG (Lewis, Dave) Date: Wed, 11 Jul 2012 22:45:05 -0400 Subject: [OpenAFS] empty /afs In-Reply-To: References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> Message-ID: <2586A1048152BE4D861E64A98700AD420B1EFAF8@nki-mail.NKI.rfmh.org> Thanks -- I'll look into having the afs client startup script check that the afs server is up first. > -----Original Message----- > From: Dan Hyde [mailto:drh@umich.edu] > Sent: Wednesday, July 11, 2012 9:44 PM > To: Lewis, Dave > Cc: > Subject: Re: [OpenAFS] empty /afs >=20 > There be dragons. We learned the had way a long time ago that it is > possible to have your server require you have a working client before > the server would start (before it had access to what the client could > provide). Please reconsider. >=20 Conserve Resources. Print only when necessary. IMPORTANT NOTICE: This e-mail is meant only for the use of the intended r= ecipient. It may contain confidential information which is legally privil= egedor otherwise protected by law. If you received this e-mail in error o= r from someone who is not authorized to send it to you, you are strictly = prohibited from reviewing, using, disseminating, distributing or copying = the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AN= D DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation. From qchang@sri.utoronto.ca Thu Jul 12 16:16:55 2012 From: qchang@sri.utoronto.ca (Qing Chang) Date: Thu, 12 Jul 2012 11:16:55 -0400 Subject: [OpenAFS] IPA + OpenAFS In-Reply-To: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> Message-ID: <4FFEEA67.6030503@sri.utoronto.ca> This is a multi-part message in MIME format. --------------020309040106010205050806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings, As recommended, you should create an AFS service principal as afs/DOMAIN@REALM, eg, afs/sri.utoronto.ca. IPA does not allow a service principal to be created if there is no corresponding host principal. Hence, I have to have this: afs/openafs.sri.utoronto.ca, where openafs.sri.utoronto.ca is the FQDN of the server. OpenAFS seems to be happy with this, and by following the quick-start guide I have setup the first server on my RHEL 6.3 server. Now I am at "Configuring the Top Levels of the AFS Filespace", after kinit and aklog, this fails: [root@smb1 ~]# fs setacl /afs system:anyuser rl fs: You don't have the required access rights on '/afs' I found this thread: http://lists.openafs.org/pipermail/openafs-info/2008-December/030552.html which says that I have to create a keyfile with des-cbc-crc:v4 salt, after some struggle with IPA I finally created the keyfile with des-cbc-crc:v4. It did not help, I still get the same error. ===== [root@smb1 ~]# bos status smb1 Instance buserver, currently running normally. Instance ptserver, currently running normally. Instance vlserver, currently running normally. Instance dafs, currently running normally. Auxiliary status is: file server running. Instance upserver, currently running normally. [root@smb1 ~]# kinit admin [root@smb1 ~]# aklog -d Authenticating to cell openafs.sri.utoronto.ca (server smb1.sri.utoronto.ca). Trying to authenticate to user's realm SRI.UTORONTO.CA. Getting tickets: afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA Using Kerberos V5 ticket natively About to resolve name admin to id in cell openafs.sri.utoronto.ca. Id 1 Set username to AFS ID 1 Setting tokens. AFS ID 1 @ openafs.sri.utoronto.ca [root@smb1 ~]# klist -e Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin@SRI.UTORONTO.CA Valid starting Expires Service principal 07/12/12 10:56:17 07/13/12 10:56:10 krbtgt/SRI.UTORONTO.CA@SRI.UTORONTO.CA Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 07/12/12 10:56:29 07/13/12 10:56:10 afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA Etype (skey, tkt): des-cbc-crc, des-cbc-crc [root@smb1 ~]# fs setacl /afs system:anyuser rl fs: You don't have the required access rights on '/afs' ===== All logs seem OK except this: [root@smb1 ~]# cat /usr/afs/logs/FileLog Wed Jul 11 15:45:27 2012 File server starting (/usr/afs/bin/dafileserver) Wed Jul 11 15:45:27 2012 afs_krb_get_lrealm failed, using openafs.sri.utoronto.ca. Wed Jul 11 15:45:30 2012 VL_RegisterAddrs rpc failed; will retry periodically (code=5376, err=0) Wed Jul 11 15:45:30 2012 VLRU: starting scanner with the following configuration parameters: Wed Jul 11 15:45:30 2012 VLRU: offlining volumes after minimum of 7200 seconds of inactivity Wed Jul 11 15:45:30 2012 VLRU: running VLRU soft detach pass every 120 seconds Wed Jul 11 15:45:30 2012 VLRU: taking up to 8 volumes offline per pass Wed Jul 11 15:45:30 2012 VLRU: scanning generation 0 for inactive volumes every 900 seconds Wed Jul 11 15:45:30 2012 VLRU: scanning for promotion/demotion between generations 0 and 1 every 14400 seconds Wed Jul 11 15:45:30 2012 VLRU: scanning for promotion/demotion between generations 1 and 2 every 28800 seconds Wed Jul 11 15:45:30 2012 Set thread id 3 for FSYNC_sync Wed Jul 11 15:45:30 2012 VInitVolumePackage: beginning parallel fileserver startup Wed Jul 11 15:45:30 2012 VInitVolumePackage: using 1 threads to pre-attach volumes on 1 partitions Wed Jul 11 15:45:30 2012 Scanning partitions on thread 1 of 1 Wed Jul 11 15:45:30 2012 Partition /vicepa: pre-attaching volumes Wed Jul 11 15:45:30 2012 Partition scan thread 1 of 1 ended Wed Jul 11 15:45:30 2012 fs_stateRestore: commencing fileserver state restore Wed Jul 11 15:45:30 2012 fs_stateRestore: host table restored Wed Jul 11 15:45:30 2012 fs_stateRestore: FileEntry and CallBack tables restored Wed Jul 11 15:45:30 2012 fs_stateRestore: host table indices remapped Wed Jul 11 15:45:30 2012 fs_stateRestore: FileEntry and CallBack indices remapped Wed Jul 11 15:45:30 2012 fs_stateRestore: restore phase complete Wed Jul 11 15:45:30 2012 fs_stateRestore: beginning state verification phase Wed Jul 11 15:45:30 2012 fs_stateRestore: fileserver state verification complete Wed Jul 11 15:45:30 2012 fs_stateRestore: restore was successful Wed Jul 11 15:45:30 2012 Getting FileServer name... Wed Jul 11 15:45:30 2012 FileServer host name is 'smb1.sri.utoronto.ca' Wed Jul 11 15:45:30 2012 Getting FileServer address... Wed Jul 11 15:45:30 2012 Set thread id 0000000000000010 for 'HostCheckLWP' Wed Jul 11 15:45:30 2012 FileServer smb1.sri.utoronto.ca has address x.x.x.x Wed Jul 11 15:45:30 2012 File Server started Wed Jul 11 15:45:30 2012 Wed Jul 11 15:45:30 2012 Set thread id 000000000000000B for 'FiveMinuteCheckLWP' Wed Jul 11 15:45:30 2012 Set thread id 000000000000000C for 'FsyncCheckLWP' Thanks, Qing --------------020309040106010205050806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings,

As recommended, you should create an AFS service principal as afs/DOMAIN@REALM,
eg, afs/sri.utoronto.ca. IPA does not allow a service principal to be created if there is
no corresponding host principal. Hence, I have to have this: afs/openafs.sri.utoronto.ca,
where openafs.sri.utoronto.ca is the FQDN of the server. OpenAFS seems to be happy
with this, and by following the quick-start guide I have setup the first server on my
RHEL 6.3 server. Now I am at "Configuring the Top Levels of the AFS Filespace", after kinit and aklog,
this fails:
[root@smb1 ~]# fs setacl /afs system:anyuser rl
fs: You don't have the required access rights on '/afs'

I found this thread: 
http://lists.openafs.org/pipermail/openafs-info/2008-December/030552.html

which says that I have to create a keyfile with des-cbc-crc:v4 salt, after
some struggle with IPA I finally created the keyfile with des-cbc-crc:v4.
It did not help, I still get the same error.

===== 
[root@smb1 ~]# bos status smb1
Instance buserver, currently running normally.
Instance ptserver, currently running normally.
Instance vlserver, currently running normally.
Instance dafs, currently running normally.
    Auxiliary status is: file server running.
Instance upserver, currently running normally.

[root@smb1 ~]# kinit admin
[root@smb1 ~]# aklog -d
Authenticating to cell openafs.sri.utoronto.ca (server smb1.sri.utoronto.ca).
Trying to authenticate to user's realm SRI.UTORONTO.CA.
Getting tickets: afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA
Using Kerberos V5 ticket natively
About to resolve name admin to id in cell openafs.sri.utoronto.ca.
Id 1
Set username to AFS ID 1
Setting tokens. AFS ID 1 @ openafs.sri.utoronto.ca

[root@smb1 ~]# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@SRI.UTORONTO.CA

Valid starting     Expires            Service principal
07/12/12 10:56:17  07/13/12 10:56:10  krbtgt/SRI.UTORONTO.CA@SRI.UTORONTO.CA
        Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
07/12/12 10:56:29  07/13/12 10:56:10  afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA
        Etype (skey, tkt): des-cbc-crc, des-cbc-crc

[root@smb1 ~]# fs setacl /afs system:anyuser rl
fs: You don't have the required access rights on '/afs'
=====

All logs seem OK except this:
[root@smb1 ~]# cat /usr/afs/logs/FileLog
Wed Jul 11 15:45:27 2012 File server starting (/usr/afs/bin/dafileserver)
Wed Jul 11 15:45:27 2012 afs_krb_get_lrealm failed, using openafs.sri.utoronto.ca.
Wed Jul 11 15:45:30 2012 VL_RegisterAddrs rpc failed; will retry periodically (code=5376, err=0)
Wed Jul 11 15:45:30 2012 VLRU: starting scanner with the following configuration parameters:
Wed Jul 11 15:45:30 2012 VLRU:  offlining volumes after minimum of 7200 seconds of inactivity
Wed Jul 11 15:45:30 2012 VLRU:  running VLRU soft detach pass every 120 seconds
Wed Jul 11 15:45:30 2012 VLRU:  taking up to 8 volumes offline per pass
Wed Jul 11 15:45:30 2012 VLRU:  scanning generation 0 for inactive volumes every 900 seconds
Wed Jul 11 15:45:30 2012 VLRU:  scanning for promotion/demotion between generations 0 and 1 every 14400 seconds
Wed Jul 11 15:45:30 2012 VLRU:  scanning for promotion/demotion between generations 1 and 2 every 28800 seconds
Wed Jul 11 15:45:30 2012 Set thread id 3 for FSYNC_sync
Wed Jul 11 15:45:30 2012 VInitVolumePackage: beginning parallel fileserver startup
Wed Jul 11 15:45:30 2012 VInitVolumePackage: using 1 threads to pre-attach volumes on 1 partitions
Wed Jul 11 15:45:30 2012 Scanning partitions on thread 1 of 1
Wed Jul 11 15:45:30 2012 Partition /vicepa: pre-attaching volumes
Wed Jul 11 15:45:30 2012 Partition scan thread 1 of 1 ended
Wed Jul 11 15:45:30 2012 fs_stateRestore: commencing fileserver state restore
Wed Jul 11 15:45:30 2012 fs_stateRestore: host table restored
Wed Jul 11 15:45:30 2012 fs_stateRestore: FileEntry and CallBack tables restored
Wed Jul 11 15:45:30 2012 fs_stateRestore: host table indices remapped
Wed Jul 11 15:45:30 2012 fs_stateRestore: FileEntry and CallBack indices remapped
Wed Jul 11 15:45:30 2012 fs_stateRestore: restore phase complete
Wed Jul 11 15:45:30 2012 fs_stateRestore: beginning state verification phase
Wed Jul 11 15:45:30 2012 fs_stateRestore: fileserver state verification complete
Wed Jul 11 15:45:30 2012 fs_stateRestore: restore was successful
Wed Jul 11 15:45:30 2012 Getting FileServer name...
Wed Jul 11 15:45:30 2012 FileServer host name is 'smb1.sri.utoronto.ca'
Wed Jul 11 15:45:30 2012 Getting FileServer address...
Wed Jul 11 15:45:30 2012 Set thread id 0000000000000010 for 'HostCheckLWP'
Wed Jul 11 15:45:30 2012 FileServer smb1.sri.utoronto.ca has address x.x.x.x
Wed Jul 11 15:45:30 2012 File Server started Wed Jul 11 15:45:30 2012
Wed Jul 11 15:45:30 2012 Set thread id 000000000000000B for 'FiveMinuteCheckLWP'
Wed Jul 11 15:45:30 2012 Set thread id 000000000000000C for 'FsyncCheckLWP'
Thanks,

Qing

--------------020309040106010205050806-- From adeason@sinenomine.net Thu Jul 12 20:25:52 2012 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 12 Jul 2012 14:25:52 -0500 Subject: [OpenAFS] Re: IPA + OpenAFS References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> <4FFEEA67.6030503@sri.utoronto.ca> Message-ID: <20120712142552.cfa26fa4.adeason@sinenomine.net> On Thu, 12 Jul 2012 11:16:55 -0400 Qing Chang wrote: > which says that I have to create a keyfile with des-cbc-crc:v4 salt, > after some struggle with IPA I finally created the keyfile with > des-cbc-crc:v4. It did not help, I still get the same error. Did you just extract a keytab, or did you also add the key to the KeyFile using 'asetkey'? This is described on the page 'Initializing Cell Security' around step 7: . If you did actually create a KeyFile, you need to restart the server processes for it to take effect. (Or 'touch' the server-side CellServDB file.) You can run 'bos listkeys -local' to show what keys the server thinks it has (don't show this output to the list). You should have at least one key listed if everything is set up correctly. -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Thu Jul 12 20:35:03 2012 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 12 Jul 2012 14:35:03 -0500 Subject: [OpenAFS] Re: IPA + OpenAFS References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> <4FFEEA67.6030503@sri.utoronto.ca> Message-ID: <20120712143503.f09e4225.adeason@sinenomine.net> On Thu, 12 Jul 2012 11:16:55 -0400 Qing Chang wrote: > As recommended, you should create an AFS service principal as > afs/DOMAIN@REALM, eg, afs/sri.utoronto.ca. IPA does not allow a > service principal to be created if there is no corresponding host > principal. Hence, I have to have this: afs/openafs.sri.utoronto.ca, > where openafs.sri.utoronto.ca is the FQDN of the server. OpenAFS seems > to be happy with this, I forgot to mention... if it wasn't clear, this means that your cell name will be openafs.sri.utoronto.ca, not sri.utoronto.ca. That's not a problem if you're okay with that, but it may look a little funny; it's like having an email address like . It also may be a little confusing, since if you ever have more than one server for the cell, afs/openafs.sri.utoronto.ca will be used by several servers with different FQDNs, not just openafs.sri. I haven't used IPA, but I assume you could create a host principal for sri.utoronto.ca and then just not use it, to get around that restriction. But that's not required. -- Andrew Deason adeason@sinenomine.net From qchang@sri.utoronto.ca Thu Jul 12 20:39:05 2012 From: qchang@sri.utoronto.ca (Qing Chang) Date: Thu, 12 Jul 2012 15:39:05 -0400 Subject: [OpenAFS] Re: IPA + OpenAFS In-Reply-To: <20120712142552.cfa26fa4.adeason@sinenomine.net> References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> <4FFEEA67.6030503@sri.utoronto.ca> <20120712142552.cfa26fa4.adeason@sinenomine.net> Message-ID: <4FFF27D9.3040206@sri.utoronto.ca> This is a multi-part message in MIME format. --------------070906060200060008050608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/07/2012 3:25 PM, Andrew Deason wrote: > On Thu, 12 Jul 2012 11:16:55 -0400 > Qing Chang wrote: > >> which says that I have to create a keyfile with des-cbc-crc:v4 salt, >> after some struggle with IPA I finally created the keyfile with >> des-cbc-crc:v4. It did not help, I still get the same error. > Did you just extract a keytab, or did you also add the key to the > KeyFile using 'asetkey'? This is described on the page 'Initializing > Cell Security' around step 7: > . I did use asetkey to add the key with thr right vno to KeyFile. But I was wrong in assuming that I got a keytab with salt: ===== kadmin.local: ktadd -e des-cbc-crc:v4 -k /tmp/openafs afs/openafs.sri.utoronto.ca Entry for principal afs/openafs.sri.utoronto.ca with kvno 20, encryption type des-cbc-crc added to keytab WRFILE:/tmp/openafs. kadmin.local: getprinc afs/openafs.sri.utoronto.ca Principal: afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA Expiration date: [never] Last password change: Thu Jul 12 15:08:16 EDT 2012 Password expiration date: [none] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Thu Jul 12 15:08:16 EDT 2012 (admin/admin@SRI.UTORONTO.CA) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 20, des-cbc-crc, no salt MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] ===== I am asking a solution on FreeIPA list to create a keytab with salt for cbc, in the mean time, does anyone know definitively if the keytab has to phave salt? Thanks, Qing > If you did actually create a KeyFile, you need to restart the server > processes for it to take effect. (Or 'touch' the server-side CellServDB > file.) You can run 'bos listkeys -local' to show what keys the > server thinks it has (don't show this output to the list). You should > have at least one key listed if everything is set up correctly. > --------------070906060200060008050608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 12/07/2012 3:25 PM, Andrew Deason wrote: 
On Thu, 12 Jul 2012 11:16:55 -0400
Qing Chang <qchang@sri.utoronto.ca> wrote:


which says that I have to create a keyfile with des-cbc-crc:v4 salt,
after some struggle with IPA I finally created the keyfile with
des-cbc-crc:v4.  It did not help, I still get the same error.

Did you just extract a keytab, or did you also add the key to the
KeyFile using 'asetkey'? This is described on the page 'Initializing
Cell Security' around step 7:
<http://docs.openafs.org/QuickStartUnix/ch02s14.html>.
I did use asetkey to add the key with thr right vno to KeyFile. But I was
wrong in assuming that I got a keytab with salt:
=====
kadmin.local:   ktadd -e des-cbc-crc:v4 -k /tmp/openafs afs/openafs.sri.utoronto.ca
Entry for principal afs/openafs.sri.utoronto.ca with kvno 20, encryption type des-cbc-crc added to keytab WRFILE:/tmp/openafs.
kadmin.local:  getprinc afs/openafs.sri.utoronto.ca
Principal: afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA
Expiration date: [never]
Last password change: Thu Jul 12 15:08:16 EDT 2012
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Jul 12 15:08:16 EDT 2012 (admin/admin@SRI.UTORONTO.CA)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 20, des-cbc-crc, no salt
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
=====

I am asking a solution on FreeIPA list to create a keytab with salt for cbc, in the
mean time, does anyone know definitively if the keytab has to phave salt?

Thanks,
Qing

If you did actually create a KeyFile, you need to restart the server
processes for it to take effect. (Or 'touch' the server-side CellServDB
file.) You can run 'bos listkeys <server> -local' to show what keys the
server thinks it has (don't show this output to the list). You should
have at least one key listed if everything is set up correctly.
--------------070906060200060008050608-- From qchang@sri.utoronto.ca Thu Jul 12 20:45:57 2012 From: qchang@sri.utoronto.ca (Qing Chang) Date: Thu, 12 Jul 2012 15:45:57 -0400 Subject: [OpenAFS] Re: IPA + OpenAFS In-Reply-To: <20120712143503.f09e4225.adeason@sinenomine.net> References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> <4FFEEA67.6030503@sri.utoronto.ca> <20120712143503.f09e4225.adeason@sinenomine.net> Message-ID: <4FFF2975.1030004@sri.utoronto.ca> This is a multi-part message in MIME format. --------------070305010100010103010403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/07/2012 3:35 PM, Andrew Deason wrote: > On Thu, 12 Jul 2012 11:16:55 -0400 > Qing Chang wrote: > >> As recommended, you should create an AFS service principal as >> afs/DOMAIN@REALM, eg, afs/sri.utoronto.ca. IPA does not allow a >> service principal to be created if there is no corresponding host >> principal. Hence, I have to have this: afs/openafs.sri.utoronto.ca, >> where openafs.sri.utoronto.ca is the FQDN of the server. OpenAFS seems >> to be happy with this, > I forgot to mention... if it wasn't clear, this means that your cell > name will be openafs.sri.utoronto.ca, not sri.utoronto.ca. That's not a > problem if you're okay with that, but it may look a little funny; it's > like having an email address like. It > also may be a little confusing, since if you ever have more than one > server for the cell, afs/openafs.sri.utoronto.ca will be used by several > servers with different FQDNs, not just openafs.sri. > > I haven't used IPA, but I assume you could create a host principal for > sri.utoronto.ca and then just not use it, to get around that > restriction. But that's not required. > thank you very much Andrew, at least I know I am not fighting 2 battles at once. I was thinking of doing just that but settled on creating a CNAME as openafs for the host smb1 that is also a test Samba server. I hope this is not causing the error message in /usr/afs/logs/FileLog: Wed Jul 11 15:45:27 2012 afs_krb_get_lrealm failed, using openafs.sri.utoronto.ca. I'll do that when this moves to production... Qing --------------070305010100010103010403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 12/07/2012 3:35 PM, Andrew Deason wrote: 
On Thu, 12 Jul 2012 11:16:55 -0400
Qing Chang <qchang@sri.utoronto.ca> wrote:


As recommended, you should create an AFS service principal as
afs/DOMAIN@REALM, eg, afs/sri.utoronto.ca. IPA does not allow a
service principal to be created if there is no corresponding host
principal. Hence, I have to have this: afs/openafs.sri.utoronto.ca,
where openafs.sri.utoronto.ca is the FQDN of the server. OpenAFS seems
to be happy with this,

I forgot to mention... if it wasn't clear, this means that your cell
name will be openafs.sri.utoronto.ca, not sri.utoronto.ca. That's not a
problem if you're okay with that, but it may look a little funny; it's
like having an email address like <qchang@sendmail.sri.utoronto.ca>. It
also may be a little confusing, since if you ever have more than one
server for the cell, afs/openafs.sri.utoronto.ca will be used by several
servers with different FQDNs, not just openafs.sri.

I haven't used IPA, but I assume you could create a host principal for
sri.utoronto.ca and then just not use it, to get around that
restriction. But that's not required.
thank you very much Andrew, at least I know I am not fighting 2 battles at once.
I was thinking of doing just that but settled on creating a CNAME as openafs for
the host smb1 that is also a test Samba server. I hope this is not causing the error
message in /usr/afs/logs/FileLog:
Wed Jul 11 15:45:27 2012 afs_krb_get_lrealm failed, using openafs.sri.utoronto.ca.


I'll do that when this moves to production...

Qing
--------------070305010100010103010403-- From adeason@sinenomine.net Thu Jul 12 20:49:39 2012 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 12 Jul 2012 14:49:39 -0500 Subject: [OpenAFS] Re: IPA + OpenAFS References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> <4FFEEA67.6030503@sri.utoronto.ca> <20120712142552.cfa26fa4.adeason@sinenomine.net> <4FFF27D9.3040206@sri.utoronto.ca> Message-ID: <20120712144939.a2ec3f36.adeason@sinenomine.net> On Thu, 12 Jul 2012 15:39:05 -0400 Qing Chang wrote: > I did use asetkey to add the key with thr right vno to KeyFile. But I > was wrong in assuming that I got a keytab with salt: > ===== > kadmin.local: ktadd -e des-cbc-crc:v4 -k /tmp/openafs afs/openafs.sri.utoronto.ca [...] > kadmin.local: getprinc afs/openafs.sri.utoronto.ca [...] > Key: vno 20, des-cbc-crc, no salt > > I am asking a solution on FreeIPA list to create a keytab with salt > for cbc, in the mean time, does anyone know definitively if the keytab > has to phave salt? No, that's fine. iirc, that's what a v4 salt is: no salt. What exactly did you run when you ran asetkey? Check: asetkey list bos listkeys -local To see if they list a key with kvno 20. Do not send the output of those commands to the list, just say which kvnos are listed. -- Andrew Deason adeason@sinenomine.net From qchang@sri.utoronto.ca Thu Jul 12 22:18:52 2012 From: qchang@sri.utoronto.ca (Qing Chang) Date: Thu, 12 Jul 2012 17:18:52 -0400 Subject: Fwd: Re: [OpenAFS] Re: IPA + OpenAFS In-Reply-To: <4FFF3EAC.2030202@sri.utoronto.ca> References: <4FFF3EAC.2030202@sri.utoronto.ca> Message-ID: <4FFF3F3C.8060105@sri.utoronto.ca> On 12/07/2012 4:47 PM, Andrew Deason wrote: > On Thu, 12 Jul 2012 15:10:36 -0500 > Qing Chang wrote: > >> [root@smb1 ~]# asetkey list >> kvno 20: > I assume you removed the actual key from this output? That is, 'asetkey' > did show a key there. What about 'bos listkeys'? Can you run 'kvno > afs/openafs.sri.utoronto.ca' after authenticating? Are there any > afs-related messages in /var/log/messages? (or /var/log/syslog, or > whatever; 'dmesg' should also show them) yes, I removed the key displayed. [root@smb1 log]# bos listkeys -server smb1 bos: you are not authorized for this operation error encountered while listing keys [root@smb1 log]# kvno afs/openafs.sri.utoronto.ca afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA: kvno = 20 [root@smb1 log]# dmesg |grep -i afs openafs: module license 'http://www.openafs.org/dl/license10.html' taints kernel. Starting AFS cache scan...found 1 non-empty cache files (0%). SELinux: initialized (dev afs, type afs), uses genfs_contexts >> [root@smb1 ~]# fs setacl /afs system:anyuser rl >> fs: You don't have the required access rights on '/afs' > Also, you don't need to do this if you are running with 'dynroot' (an > option that can be turned off or on in the init script configuration). I > thought we gave a different error in that case, but perhaps that is it. > Is there anything in /afs ? Does 'fs listacl /afs' show anything? I actually removed dynroot because of the timeout error message. Now I put dynroot back and get this as expected: [root@smb1 ~]# fs setacl /afs system:anyuser rl fs:'/afs': Connection timed out [root@smb1 ~]# fs listacl /afs fs:'/afs': Connection timed out /afs has the global afs structure plus my cell: [root@smb1 ~]# ls -l /afs total 802 ..... drwxr-xr-x. 100 root root 4096 Dec 31 1969 numenor.mit.edu drwxr-xr-x. 100 root root 4096 Dec 31 1969 oc7.org drwxr-xr-x. 100 root root 4096 Dec 31 1969 openafs.sri.utoronto.ca drwxr-xr-x. 100 root root 4096 Dec 31 1969 pdc.kth.se ..... Qing From qchang@sri.utoronto.ca Thu Jul 12 22:27:37 2012 From: qchang@sri.utoronto.ca (Qing Chang) Date: Thu, 12 Jul 2012 17:27:37 -0400 Subject: Fwd: Re: [OpenAFS] Re: IPA + OpenAFS In-Reply-To: <4FFF3F3C.8060105@sri.utoronto.ca> References: <4FFF3EAC.2030202@sri.utoronto.ca> <4FFF3F3C.8060105@sri.utoronto.ca> Message-ID: <4FFF4149.6040004@sri.utoronto.ca> On 12/07/2012 5:18 PM, Qing Chang wrote: > > On 12/07/2012 4:47 PM, Andrew Deason wrote: >> On Thu, 12 Jul 2012 15:10:36 -0500 >> Qing Chang wrote: >> >>> [root@smb1 ~]# asetkey list >>> kvno 20: >> I assume you removed the actual key from this output? That is, 'asetkey' >> did show a key there. What about 'bos listkeys'? Can you run 'kvno >> afs/openafs.sri.utoronto.ca' after authenticating? Are there any >> afs-related messages in /var/log/messages? (or /var/log/syslog, or >> whatever; 'dmesg' should also show them) > yes, I removed the key displayed. > > [root@smb1 log]# bos listkeys -server smb1 > bos: you are not authorized for this operation error encountered while listing keys > [root@smb1 sysadmin]# bos listkeys -server smb1 -localauth key 20 has cksum 1880145215 Keys last changed on Thu Jul 12 15:59:59 2012. All done. > [root@smb1 log]# kvno afs/openafs.sri.utoronto.ca > afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA: kvno = 20 > > [root@smb1 log]# dmesg |grep -i afs > openafs: module license 'http://www.openafs.org/dl/license10.html' taints kernel. > Starting AFS cache scan...found 1 non-empty cache files (0%). > SELinux: initialized (dev afs, type afs), uses genfs_contexts > >>> [root@smb1 ~]# fs setacl /afs system:anyuser rl >>> fs: You don't have the required access rights on '/afs' >> Also, you don't need to do this if you are running with 'dynroot' (an >> option that can be turned off or on in the init script configuration). I >> thought we gave a different error in that case, but perhaps that is it. >> Is there anything in /afs ? Does 'fs listacl /afs' show anything? > I actually removed dynroot because of the timeout error message. Now I put dynroot > back and get this as expected: > [root@smb1 ~]# fs setacl /afs system:anyuser rl > fs:'/afs': Connection timed out > > [root@smb1 ~]# fs listacl /afs > fs:'/afs': Connection timed out > > /afs has the global afs structure plus my cell: > [root@smb1 ~]# ls -l /afs > total 802 > ..... > drwxr-xr-x. 100 root root 4096 Dec 31 1969 numenor.mit.edu > drwxr-xr-x. 100 root root 4096 Dec 31 1969 oc7.org > drwxr-xr-x. 100 root root 4096 Dec 31 1969 openafs.sri.utoronto.ca > drwxr-xr-x. 100 root root 4096 Dec 31 1969 pdc.kth.se > ..... > > Qing > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From adeason@sinenomine.net Thu Jul 12 22:52:51 2012 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 12 Jul 2012 16:52:51 -0500 Subject: [OpenAFS] Re: Fwd: Re: Re: IPA + OpenAFS References: <4FFF3EAC.2030202@sri.utoronto.ca> <4FFF3F3C.8060105@sri.utoronto.ca> Message-ID: <20120712165251.95c47cb6.adeason@sinenomine.net> On Thu, 12 Jul 2012 17:18:52 -0400 Qing Chang wrote: > [root@smb1 log]# kvno afs/openafs.sri.utoronto.ca > afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA: kvno = 20 Ah, right. Since you changed your cell name to openafs.sri.utoronto.ca, your cell and realm name do not match. When the name of your cell and realm are different, you need to put the realm name you want to use in /usr/afs/etc/krb.conf; you haven't done that, have you? Just put the name of the realm (SRI.UTORONTO.CA) in that file by itself. For reference: . And restart the server (to be clear, you don't need to reboot the whole system when I say that; just use the init script to restart the openafs server processes). -- Andrew Deason adeason@sinenomine.net From qchang@sri.utoronto.ca Fri Jul 13 15:15:50 2012 From: qchang@sri.utoronto.ca (Qing Chang) Date: Fri, 13 Jul 2012 10:15:50 -0400 Subject: [OpenAFS] Re: Fwd: Re: Re: IPA + OpenAFS In-Reply-To: <20120712165251.95c47cb6.adeason@sinenomine.net> References: <4FFF3EAC.2030202@sri.utoronto.ca> <4FFF3F3C.8060105@sri.utoronto.ca> <20120712165251.95c47cb6.adeason@sinenomine.net> Message-ID: <50002D96.5090107@sri.utoronto.ca> On 12/07/2012 5:52 PM, Andrew Deason wrote: > On Thu, 12 Jul 2012 17:18:52 -0400 > Qing Chang wrote: > >> [root@smb1 log]# kvno afs/openafs.sri.utoronto.ca >> afs/openafs.sri.utoronto.ca@SRI.UTORONTO.CA: kvno = 20 > Ah, right. Since you changed your cell name to openafs.sri.utoronto.ca, > your cell and realm name do not match. When the name of your cell and > realm are different, you need to put the realm name you want to use in > /usr/afs/etc/krb.conf; you haven't done that, have you? Silly me, I just copied system krb5.conf to the location without really noticing the difference in name and syntax... [root@smb1 etc]# cat /usr/afs/etc/krb5.conf # Realm mapping: SRI.UTORONTO.CA But I am still stuck: [root@smb1 ~]# fs listacl /afs fs:'/afs': Connection timed out [root@smb1 ~]# vos create smb1 /vicepa root.cell Could not get an Id for volume root.cell VLDB: no permission access for call VLDB: no permission access for call Error in vos create command. VLDB: no permission access for call Qing > Just put the name of the realm (SRI.UTORONTO.CA) in that file by itself. > For reference:. And > restart the server (to be clear, you don't need to reboot the whole > system when I say that; just use the init script to restart the openafs > server processes). > From adeason@sinenomine.net Fri Jul 13 15:47:40 2012 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 13 Jul 2012 09:47:40 -0500 Subject: [OpenAFS] Re: IPA + OpenAFS References: <4FFF3EAC.2030202@sri.utoronto.ca> <4FFF3F3C.8060105@sri.utoronto.ca> <20120712165251.95c47cb6.adeason@sinenomine.net> <50002D96.5090107@sri.utoronto.ca> Message-ID: <20120713094740.866a69b8.adeason@sinenomine.net> On Fri, 13 Jul 2012 10:15:50 -0400 Qing Chang wrote: > Silly me, I just copied system krb5.conf to the location without > really noticing the difference in name and syntax... > [root@smb1 etc]# cat /usr/afs/etc/krb5.conf > # Realm mapping: > SRI.UTORONTO.CA The file is krb.conf, not krb5.conf. And don't put any comments in the file; the only thing in that file should be the realm name, by itself. You want it to look like: [root@smb1 etc]# cat /usr/afs/etc/krb.conf SRI.UTORONTO.CA [root@smb1 etc]# > But I am still stuck: > [root@smb1 ~]# fs listacl /afs > fs:'/afs': Connection timed out That's going to keep happening if you're using dynroot; that's unrelated to your issues. -- Andrew Deason adeason@sinenomine.net From qchang@sri.utoronto.ca Fri Jul 13 16:40:37 2012 From: qchang@sri.utoronto.ca (Qing Chang) Date: Fri, 13 Jul 2012 11:40:37 -0400 Subject: [OpenAFS] Re: IPA + OpenAFS In-Reply-To: <20120713094740.866a69b8.adeason@sinenomine.net> References: <4FFF3EAC.2030202@sri.utoronto.ca> <4FFF3F3C.8060105@sri.utoronto.ca> <20120712165251.95c47cb6.adeason@sinenomine.net> <50002D96.5090107@sri.utoronto.ca> <20120713094740.866a69b8.adeason@sinenomine.net> Message-ID: <50004175.7050104@sri.utoronto.ca> This is a multi-part message in MIME format. --------------030703060104080008070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Many many thanks. After removing the comment line, I got this: [root@smb1 etc]# vos create smb1 /vicepa root.cell Volume 536870915 created on partition /vicepa of smb1 Though I get this the next: [root@smb1 etc]# fs mkmount /afs/openafs.sri.utoronto.ca root.cell fs: cell dynroot not in /usr/vice/etc/CellServDB [root@smb1 etc]# cat /usr/vice/etc/CellServDB >openafs.sri.utoronto.ca #Cell name 142.76.29.40 #smb1.sri.utoronto.ca [root@smb1 etc]# ls -l /afs drwxr-xr-x. 100 root root 4096 Dec 31 1969 openafs.sri.utoronto.ca Qing On 13/07/2012 10:47 AM, Andrew Deason wrote: > On Fri, 13 Jul 2012 10:15:50 -0400 > Qing Chang wrote: > >> Silly me, I just copied system krb5.conf to the location without >> really noticing the difference in name and syntax... >> [root@smb1 etc]# cat /usr/afs/etc/krb5.conf >> # Realm mapping: >> SRI.UTORONTO.CA > The file is krb.conf, not krb5.conf. And don't put any comments in the > file; the only thing in that file should be the realm name, by itself. > You want it to look like: > > [root@smb1 etc]# cat /usr/afs/etc/krb.conf > SRI.UTORONTO.CA > [root@smb1 etc]# > >> But I am still stuck: >> [root@smb1 ~]# fs listacl /afs >> fs:'/afs': Connection timed out > That's going to keep happening if you're using dynroot; that's unrelated > to your issues. > --------------030703060104080008070208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Many many thanks.

After removing the comment line, I got this:
[root@smb1 etc]# vos create  smb1 /vicepa root.cell
Volume 536870915 created on partition /vicepa of smb1

Though I get this the next:
[root@smb1 etc]# fs mkmount /afs/openafs.sri.utoronto.ca  root.cell
fs: cell dynroot not in /usr/vice/etc/CellServDB

[root@smb1 etc]# cat /usr/vice/etc/CellServDB
>openafs.sri.utoronto.ca        #Cell name
142.76.29.40    #smb1.sri.utoronto.ca

[root@smb1 etc]# ls -l /afs
drwxr-xr-x. 100 root root 4096 Dec 31  1969 openafs.sri.utoronto.ca

Qing

On 13/07/2012 10:47 AM, Andrew Deason wrote: 
On Fri, 13 Jul 2012 10:15:50 -0400
Qing Chang <qchang@sri.utoronto.ca> wrote:


Silly me, I just copied system krb5.conf to the location without
really noticing the difference in name and syntax...
[root@smb1 etc]# cat /usr/afs/etc/krb5.conf
# Realm mapping:
SRI.UTORONTO.CA

The file is krb.conf, not krb5.conf. And don't put any comments in the
file; the only thing in that file should be the realm name, by itself.
You want it to look like:

[root@smb1 etc]# cat /usr/afs/etc/krb.conf
SRI.UTORONTO.CA
[root@smb1 etc]#


But I am still stuck:
[root@smb1 ~]# fs listacl /afs
fs:'/afs': Connection timed out

That's going to keep happening if you're using dynroot; that's unrelated
to your issues.
--------------030703060104080008070208-- From shadow@gmail.com Fri Jul 13 16:47:42 2012 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 13 Jul 2012 11:47:42 -0400 Subject: [OpenAFS] Re: IPA + OpenAFS In-Reply-To: <50004175.7050104@sri.utoronto.ca> References: <4FFF3EAC.2030202@sri.utoronto.ca> <4FFF3F3C.8060105@sri.utoronto.ca> <20120712165251.95c47cb6.adeason@sinenomine.net> <50002D96.5090107@sri.utoronto.ca> <20120713094740.866a69b8.adeason@sinenomine.net> <50004175.7050104@sri.utoronto.ca> Message-ID: you're using dynroot. you don't need to (or, indeed, get to) create a mount point in /afs for root.cell. you should already have /afs/openafs.sri.utoronto.ca and /afs/.openafs.sri.utoronto.ca visible. On Fri, Jul 13, 2012 at 11:40 AM, Qing Chang wrote: > Many many thanks. > > After removing the comment line, I got this: > [root@smb1 etc]# vos create smb1 /vicepa root.cell > Volume 536870915 created on partition /vicepa of smb1 > > Though I get this the next: > [root@smb1 etc]# fs mkmount /afs/openafs.sri.utoronto.ca root.cell > fs: cell dynroot not in /usr/vice/etc/CellServDB > > [root@smb1 etc]# cat /usr/vice/etc/CellServDB >>openafs.sri.utoronto.ca #Cell name > 142.76.29.40 #smb1.sri.utoronto.ca > > [root@smb1 etc]# ls -l /afs > > drwxr-xr-x. 100 root root 4096 Dec 31 1969 openafs.sri.utoronto.ca > > Qing > > > On 13/07/2012 10:47 AM, Andrew Deason wrote: > > On Fri, 13 Jul 2012 10:15:50 -0400 > Qing Chang wrote: > > Silly me, I just copied system krb5.conf to the location without > really noticing the difference in name and syntax... > [root@smb1 etc]# cat /usr/afs/etc/krb5.conf > # Realm mapping: > SRI.UTORONTO.CA > > The file is krb.conf, not krb5.conf. And don't put any comments in the > file; the only thing in that file should be the realm name, by itself. > You want it to look like: > > [root@smb1 etc]# cat /usr/afs/etc/krb.conf > SRI.UTORONTO.CA > [root@smb1 etc]# > > But I am still stuck: > [root@smb1 ~]# fs listacl /afs > fs:'/afs': Connection timed out > > That's going to keep happening if you're using dynroot; that's unrelated > to your issues. > -- Derrick From qchang@sri.utoronto.ca Fri Jul 13 17:07:51 2012 From: qchang@sri.utoronto.ca (Qing Chang) Date: Fri, 13 Jul 2012 12:07:51 -0400 Subject: [OpenAFS] Re: IPA + OpenAFS In-Reply-To: References: <4FFF3EAC.2030202@sri.utoronto.ca> <4FFF3F3C.8060105@sri.utoronto.ca> <20120712165251.95c47cb6.adeason@sinenomine.net> <50002D96.5090107@sri.utoronto.ca> <20120713094740.866a69b8.adeason@sinenomine.net> <50004175.7050104@sri.utoronto.ca> Message-ID: <500047D7.1070403@sri.utoronto.ca> This is a multi-part message in MIME format. --------------030809080308070408050708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Much appreciated to everyone bearing with a newbie with all the dumb questions. It is indeed taken care of dynamically, this runs successfully: [root@smb1 etc]# fs setacl /afs/openafs.sri.utoronto.ca system:anyuser rl Just a humble suggestion, it would help much if there is a few words explicitly in section "Configuring the Top Levels of the AFS Filespace" or somewhere else appropriate on how dynroot would affect the process. After all the struggle with creating keytab with :v4, am I right to assume that :normal and :afs3 should work too? Is there plan to use more secure enctype in the near future? Qing On 13/07/2012 11:49 AM, Brandon Allbery wrote: > On Fri, Jul 13, 2012 at 11:40 AM, Qing Chang > wrote: > > Though I get this the next: > [root@smb1 etc]# fs mkmount /afs/openafs.sri.utoronto.ca > root.cell > fs: cell dynroot not in /usr/vice/etc/CellServDB > > > You're using dynroot; you don't need to do this, it's generated dynamically. > > -- > brandon s allbery allbery.b@gmail.com > wandering unix systems administrator (available) (412) 475-9364 vm/sms > --------------030809080308070408050708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.sri.utoronto.ca id q6DG7pCs015377 Much appreciated to everyone bearing with a newbie with all the dumb questions.

It is indeed taken care of dynamically, this runs successfully:
[root@smb1 etc]# fs setacl /afs/openafs.sri.utoronto.ca=C2=A0 system:anyuser rl

Just a humble suggestion, it would help much if there is a few words explicitly
in section "Configuring the Top Levels of the AFS Filespace"
or somewhere else appropriate on how dynroot would affect the process.=C2=A0

After all the struggle with creating keytab with :v4, am I right to assume that
:normal and :afs3 should work too?

Is there plan to use more secure enctype in the near future?

Qing

On 13/07/2012 11:49 AM, Brandon Allbery wrote:
On Fri, Jul 13, 2012 at 11:40 AM, Qing Chang <qcha= ng@sri.utoronto.ca> wrote:
Though I get this t= he next:
[root@smb1 etc]# fs mkmount /afs/openafs.sri.utoronto.ca=C2=A0 root.cell
fs: cell dynroot not in /usr/vice/etc/CellServDB

You're using dynroot; you don't need to do this, it's generated dynamically.

--
brandon s allbery =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0allbery.b@gmail.com
wandering unix systems administrator (available) =C2=A0 =C2=A0 (4= 12) 475-9364 vm/sms



  


--------------030809080308070408050708--

From allbery.b@gmail.com  Fri Jul 13 16:49:58 2012
From: allbery.b@gmail.com (Brandon Allbery)
Date: Fri, 13 Jul 2012 11:49:58 -0400
Subject: [OpenAFS] Re: IPA + OpenAFS
In-Reply-To: <50004175.7050104@sri.utoronto.ca>
References: <4FFF3EAC.2030202@sri.utoronto.ca>
 <4FFF3F3C.8060105@sri.utoronto.ca>
 <20120712165251.95c47cb6.adeason@sinenomine.net>
 <50002D96.5090107@sri.utoronto.ca>
 <20120713094740.866a69b8.adeason@sinenomine.net>
 <50004175.7050104@sri.utoronto.ca>
Message-ID: 

--e89a8fb2060645267604c4b808bf
Content-Type: text/plain; charset=UTF-8

On Fri, Jul 13, 2012 at 11:40 AM, Qing Chang  wrote:

> Though I get this the next:
> [root@smb1 etc]# fs mkmount /afs/openafs.sri.utoronto.ca  root.cell
> fs: cell dynroot not in /usr/vice/etc/CellServDB
>

You're using dynroot; you don't need to do this, it's generated dynamically.

-- 
brandon s allbery                                      allbery.b@gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

--e89a8fb2060645267604c4b808bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Fri, Jul 13, 2012 at 11:40 AM, Qing Chang <qchang=
@sri.utoronto.ca> wrote:


 =20
   =20
 =20
  
Though I get this the next:

    [root@smb1 etc]# fs mkmount /afs/openafs.sri.utoronto.ca=C2=A0 root.cell

    fs: cell dynroot not in
      /usr/vice/etc/CellServDB

=

You're using dynroot; you don't need to do this, it's gene=
rated dynamically.

-- 
brandon s allbery =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allbery.b@gmail.com

wandering unix systems administrator (available) =C2=A0 =C2=A0 (412) 475-93=
64 vm/sms





--e89a8fb2060645267604c4b808bf--

From jayen@science.unsw.edu.au  Sat Jul 14 11:42:24 2012
From: jayen@science.unsw.edu.au (Jayen Ashar)
Date: Sat, 14 Jul 2012 20:42:24 +1000
Subject: [OpenAFS] token lifetime
In-Reply-To: <28723e2d748c4dbdb136f6aa2b1a0362@INFPWXH002.ad.unsw.edu.au>
References: <1058035206.28454.8.camel@rich.habitat.thewallacepack.net>
 
  <28723e2d748c4dbdb136f6aa2b1a0362@INFPWXH002.ad.unsw.edu.au>
Message-ID: 

On Fri, Jul 6, 2012 at 6:08 PM, Jeffrey Altman
 wrote:
> The code in question is tkt_DecodeTicket5() in src/rxkad/ticket5.c and
> tkt_CheckTimes() in src/rxkad/ticket.c.    If the 'end' value is not
> exactly NEVERDATE (0xFFFFFFFF) and ('end' - 'start' is greater than
> 30 days, the token will be rejected.

I managed to make the 'end' value exactly NEVERDATE from the kerberos
server, but the client assumes it is an error:
Kerberos error code returned by get_cred : 1859794432
aklog: Couldn't get storm.ccrc.unsw.edu.au AFS tickets:
aklog: Unknown code asn1 0 (1859794432) while getting AFS tickets

Works as expected with 0xFFFFFFFE and 0, though.  (The ticket is
expired and so there are no tokens.)

Guess 30 days is the limit.

Thanks,
Jayen

From jaltman@your-file-system.com  Sun Jul 15 17:55:21 2012
From: jaltman@your-file-system.com (Jeffrey Altman)
Date: Sun, 15 Jul 2012 12:55:21 -0400
Subject: [OpenAFS] Re: [OpenAFS-devel] Re: [AFS3-std] Changing RXAFS_GetVolumeStatus
 access check to support volume lock down
In-Reply-To: <20120706.151608.354446586912967605.haba@habanero>
References: <4FF45DD6.6060000@your-file-system.com> <1341509011.3279.811.camel@destiny.pc.cs.cmu.edu> <4FF619BA.6040808@secure-endpoints.com> <20120706.151608.354446586912967605.haba@habanero>
Message-ID: <5002F5F9.7060103@your-file-system.com>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig50A3B165E40869CD37A40EB1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7/6/2012 9:16 AM, Harald Barth wrote:
> From: Jeffrey Altman 
> Subject: Re: [OpenAFS-devel] Re: [AFS3-std] Changing RXAFS_GetVolumeSta=
tus access check to support volume lock down
> Date: Thu, 05 Jul 2012 18:48:26 -0400
>=20
>> On 7/5/2012 1:23 PM, Jeffrey Hutzelman wrote:
>>> I think it is fine to skip access control checks on this call entirel=
y.
>>> As you point out, the information available via this RPC is also
>>> available to unauthenticated clients via the volserver.
>>
>> I have modified http://gerrit.openafs.org/#change,7705 to remove all
>> access control checks.  I was being conservative by changing the check=

>> to RXAFS_LOOKUP but I am in agreement that the check is not needed at =
all.
>=20
> My cents after sleeping on it...
>=20
> When there is another door open to access the building, it is not very
> useful to check ID cards at the other.

Based upon the few comments that were received, I'm going to go ahead
and approve http://gerrit.openafs.org/#change,7705 with the intention
that this change be incorporated in the 1.6.2 release.

> If this would be "restricted information" then one would have to
>=20
>  (1) Close the unauthenticated method
>=20
>  (2) Figure out what WOULD BE a useful access restriction. I think
>      that (l) on the volume root is not good. The right access
>      restriction would IMHO be "open for any user that has (w) or (i)
>      in any directory of the volume". That check is a little more
>      tricky to implement but we don't need to think about it until (1)
>      is changed.

I will start a new thread on openafs-devel to discuss the question of
viable authorization checks on the VL and VOL interfaces since at the
moment there is no authorization data to use to enforce such checks.

Jeffrey Altman



--------------enig50A3B165E40869CD37A40EB1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQAvX8AAoJENxm1CNJffh4Z2IIAN0JFlZ+P5jmpZhNjxs8ELsE
oe7WdIbCaYd16M6vJjjwckvYxr8ldYdsTm5DtBTs2EETwatLXtDO2RI0403ON+B1
+AGqM04R1HSAXZ+0tRsMY6SLq5kb8Z15zs6wZl0uIFPBcu6ujKvserrwg9WKERgH
JJ4sxJK0+h/eDIkHi+5V++VDH+oHlix8k3GrHqW2g4bgHStIb8+u/YYMQCsWJOVG
3PsEf70enawbo/0X5ouoSQjsJWY6jkneZZ5s9q9Ay1WZex7u8Z5PHUWZkswmw1gW
wIJn91WwcDQck+YjlCWtLQVpDmYWoLe1prc/HHJKK0RDTUpFr0eofGfg8NWbwkA=
=qA9c
-----END PGP SIGNATURE-----

--------------enig50A3B165E40869CD37A40EB1--


From qchang@sri.utoronto.ca  Mon Jul 16 16:02:16 2012
From: qchang@sri.utoronto.ca (Qing Chang)
Date: Mon, 16 Jul 2012 11:02:16 -0400
Subject: [OpenAFS] vos create fails with "no quorum elected"
Message-ID: <50042CF8.2040307@sri.utoronto.ca>

This is a multi-part message in MIME format.
--------------090801010006070605040906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I am following the QuickStart guide to "Storing AFS Binaries in AFS"
and got this error:
=====
[root@smb1 afs]# vos create smb1 /vicepa  afsdoc  -maxquota  0
Could not get an Id for volume afsdoc
    u: no quorum elected
u: no quorum elected
Error in vos create command.
u: no quorum elected
=====

Note this is my first OpenAFS server so there is not another DB server,
maybe something obvious is missing, please help.

Thanks,
Qing

--------------090801010006070605040906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    I am following the QuickStart guide to "Storing AFS Binaries in AFS"

    and got this error:

    =====

    [root@smb1 afs]# vos create smb1 /vicepa  afsdoc  -maxquota  0

    Could not get an Id for volume afsdoc

       u: no quorum elected

    u: no quorum elected

    Error in vos create command.

    u: no quorum elected

    =====

    

    Note this is my first OpenAFS server so there is not another DB
    server, 

    maybe something obvious is missing, please help.

    

    Thanks,

    Qing

  


--------------090801010006070605040906--

From scs@umich.edu  Mon Jul 16 16:44:36 2012
From: scs@umich.edu (Steve Simmons)
Date: Mon, 16 Jul 2012 11:44:36 -0400
Subject: [OpenAFS] empty /afs
In-Reply-To: 
References: <2586A1048152BE4D861E64A98700AD420B1EFAF6@nki-mail.NKI.rfmh.org> 
Message-ID: <515D08B8-EE9F-4805-8BFE-BA8B58027511@umich.edu>

Seconding what Dan said. Under 'normal' circumstances, you can get away =
with this. But if anything goes wrong with your afs server itself, =
you're in a deadly embrace -- since the server doesn't come up, the =
client fails and the sh*t hits the fan. Worse, if you've got server-side =
dependencies on having the afs client up (for example, other services =
run on the afs server depend on files in AFS), then it may be impossible =
to bring your file server up at all except by inserting a CD-ROM and =
hitting the power switch. And if your server doesn't happen to have a =
CD-ROM drive. . . so yeah, don't do that.

Steve

On Jul 11, 2012, at 9:44 PM, Dan Hyde wrote:

> There be dragons. We learned the had way a long time ago that it is =
possible to have your server require you have a working client before =
the server would start (before it had access to what the client could =
provide).  Please reconsider.
>=20
> On Jul 11, 2012, at 9:25 PM, "Lewis, Dave"  wrote:
>=20
>> Hi,
>>=20
>> On one of our fileservers, /afs is empty.  (We're running the AFS =
client
>> on the fileserver because I sometimes do client operations there.)  =
All
>> of our other servers and clients seem fine.
>>=20
>> I looked through the AFS log files and didn't see anything obvious =
(but
>> I could have missed something).  The /usr/vice/cache partition is =
ext3.
>>=20
>> CentOS 5.6, OpenAFS 1.4.14.1, 64-bit
>>=20
>> $ ls -la /afs
>> total 8
>> drwxr-xr-x  2 root root 4096 Apr 14  2010 ./
>> drwxr-xr-x 34 root root 4096 May 26 19:16 ../
>>=20
>> # service openafs-client status
>> afsd (pid 4320) is running...
>>=20
>> # du -sh /usr/vice/cache
>> 24M     /usr/vice/cache
>>=20
>> # cat /usr/vice/etc/cacheinfo
>> /afs:/usr/vice/cache:900000
>>=20
>> $ cat /etc/sysconfig/openafs
>> # OpenAFS Client Configuration
>> AFSD_ARGS=3D"-fakestat -stat 4000 -dcache 4000 -daemons 6 -volumes =
256
>> -files 50000 -nosettime"
>>=20
>> # OpenAFS Server Configuration
>> BOSSERVER_ARGS=3D
>>=20
>>=20
>> On another server (set up the same way):
>>=20
>> $ ls -la /afs
>> total 15
>> drwxrwxrwx  2 root root 2048 May 17  2000 ./
>> drwxr-xr-x 33 root root 4096 May 26 19:20 ../
>> lrwxr-xr-x  1 bin  root   13 May 17  2000 cabi -> cabi.rfmh.org/
>> drwxrwxrwx  2 root root 2048 Jun 14  2011 .cabi.rfmh.org/
>> drwxrwxrwx  2 root root 2048 Jun 14  2011 cabi.rfmh.org/
>>=20
>> # du -sh /usr/vice/cache
>> 827M    /usr/vice/cache
>>=20
>> Would it be safe to restart the AFS client and see if it fixes the
>> problem?  Since the computer is a server and I haven't figured out =
the
>> cause of the problem, I thought I would ask here first.
>>=20
>> Thanks,
>> Dave
>>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
>> David P. Lewis=20
>> Center for Advanced Brain Imaging, Division of Medical Physics=20
>> The Nathan S. Kline Institute for Psychiatric Research=20
>> 140 Old Orangeburg Road, Orangeburg, NY 10962=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> Conserve Resources. Print only when necessary.
>>=20
>> IMPORTANT NOTICE: This e-mail is meant only for the use of the =
intended recipient. It may contain confidential information which is =
legally privilegedor otherwise protected by law. If you received this =
e-mail in error or from someone who is not authorized to send it to you, =
you are strictly prohibited from reviewing, using, disseminating, =
distributing or copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE =
ERROR BY RETURN E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank =
you for your cooperation.
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>=20
>>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info


From scs@umich.edu  Mon Jul 16 20:07:10 2012
From: scs@umich.edu (Steve Simmons)
Date: Mon, 16 Jul 2012 15:07:10 -0400
Subject: [OpenAFS] bos backupsys silently failing for one or two volumes?
Message-ID: <584987D9-F7A1-4FE2-91D9-6D2A1A09413F@umich.edu>

It appears that periodically bos backupsys silently fails for a volume. =
I'm curious if others have seen the same issue.

We recently updated some of our AFS data gathering and internal health =
scripts to report on volumes that had not had a recent .backup volume =
created. This has mostly been a win, as it finds volumes which were left =
in a locked state, etc, etc. However, it has uncovered another problem =
where bos backupsys seems to miss a volume occasionally.

Environment - running a linux from scratch, openafs 1.4.12. We have 30 =
servers, with about 275,000 RW volumes, ie, not counting .backups and =
.readonly volumes.

Bos config for backupsys:

  bnode cron snapshot 1
  parm /usr/sbin/vos backupsys -se localhost -localauth
  parm 18:00
  end

Our new volume health checker was implemented near the end of May. It =
runs about 14 hours after the backupsys. If it sees a volume with =
.backup older than 36 hours, it will report that old backup as

   g.presoff.smartgl: 1 days, 12 hrs, 32 min

This particular volume came up on June 7. vos examine -fo verified the =
.backup being older than expected. We did a manual vos backup on it and =
was fine for a few days. It occurred again on the same value June 12, we =
did a manual backup again. On Jun 19 it hit again. This time we =
deliberately didn't do a manual backup, the next day it reported being =
an additional 24 hours out of date. We forced a backup. On Jun 22 it =
again reported being out of date, we let it go and it came up again on =
the 23rd. At that point we vos moved it from one partition to another on =
the same server, then back to the original partition. The next day, it =
once again had not gotten a .backup, but the next day it did (weekend). =
On July 5 it again had an old .backup. We then moved it to another =
server, and it has not yet thrown problems. We have had several other =
volumes generate similar errors, tho none this persistent.

The three volumes involved were on three different file servers at the =
time that the .backup volumes were not created. One of them was migrated =
to a different server and ceased being a problem, one threw only one =
error and has not complained again. All three of the servers involved =
were of the same type (hardware configuration); there are four others of =
that type active, none of which have shown any errors.

Through all of this, there were no entries in BosLog, FileLog or =
VolserLog show any reference to the volume aside from normal access =
stuff. The volumes were not locked, and normal backups (vos dump) worked =
without errors. No kernel or daemon messages were generated about disk =
problems.

Anybody seen anything like this on their systems?

Steve=

From adeason@sinenomine.net  Mon Jul 16 20:31:08 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Mon, 16 Jul 2012 14:31:08 -0500
Subject: [OpenAFS] Re: vos create fails with "no quorum elected"
References: <50042CF8.2040307@sri.utoronto.ca>
Message-ID: <20120716143108.bd766bb3.adeason@sinenomine.net>

On Mon, 16 Jul 2012 11:02:16 -0400
Qing Chang  wrote:

> [root@smb1 afs]# vos create smb1 /vicepa  afsdoc  -maxquota  0
> Could not get an Id for volume afsdoc
>     u: no quorum elected

What is the output from 'udebug  7003 -long' ?

-- 
Andrew Deason
adeason@sinenomine.net


From qchang@sri.utoronto.ca  Mon Jul 16 20:44:19 2012
From: qchang@sri.utoronto.ca (Qing Chang)
Date: Mon, 16 Jul 2012 15:44:19 -0400
Subject: [OpenAFS] Re: vos create fails with "no quorum elected"
In-Reply-To: <20120716143108.bd766bb3.adeason@sinenomine.net>
References: <50042CF8.2040307@sri.utoronto.ca> <20120716143108.bd766bb3.adeason@sinenomine.net>
Message-ID: <50046F13.4040002@sri.utoronto.ca>

This is a multi-part message in MIME format.
--------------060208020906070109070609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



On 16/07/2012 3:31 PM, Andrew Deason wrote:
> On Mon, 16 Jul 2012 11:02:16 -0400
> Qing Chang  wrote:
>
>> [root@smb1 afs]# vos create smb1 /vicepa  afsdoc  -maxquota  0
>> Could not get an Id for volume afsdoc
>>      u: no quorum elected
> What is the output from 'udebug  7003 -long' ?
[root@smb1 logs]# udebug  smb1 7003 -long
Host's addresses are: (smb1's IP)
Host's(smb1's IP) time is Mon Jul 16 15:37:57 2012
Local time is Mon Jul 16 15:37:58 2012 (time differential 1 secs)
Last yes vote not cast yet
Local db version is 1342191857.6
I am sync site forever (0 server)
Recovery state 0
The last trans I handled was 0.14
Sync site's db version is 0.0
0 locked pages, 0 of them for write

I assume the real IP address is not needed for troubleshooting, replaced in red letters.

There is repeated ebtries in /usr/afs/logs/FileLog:
=====
Mon Jul 16 15:29:21 2012 VL_RegisterAddrs rpc failed; will retry periodically (code=5389, err=0)
Mon Jul 16 15:34:21 2012 VL_RegisterAddrs rpc failed; will retry periodically (code=5389, err=0)
Mon Jul 16 15:39:21 2012 VL_RegisterAddrs rpc failed; will retry periodically (code=5389, err=0)
=====

Thank you very much.
Qing

--------------060208020906070109070609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

    On 16/07/2012 3:31 PM, Andrew Deason wrote:
    

      
On Mon, 16 Jul 2012 11:02:16 -0400
Qing Chang <qchang@sri.utoronto.ca> wrote:



      

        
[root@smb1 afs]# vos create smb1 /vicepa  afsdoc  -maxquota  0
Could not get an Id for volume afsdoc
    u: no quorum elected


      

      
What is the output from 'udebug <server> 7003 -long' ?


    

    [root@smb1 logs]# udebug  smb1 7003 -long

    Host's addresses are: (smb1's IP)

    Host's (smb1's IP) time is Mon Jul 16
    15:37:57 2012

    Local time is Mon Jul 16 15:37:58 2012 (time differential 1 secs)

    Last yes vote not cast yet

    Local db version is 1342191857.6

    I am sync site forever (0 server)

    Recovery state 0

    The last trans I handled was 0.14

    Sync site's db version is 0.0

    0 locked pages, 0 of them for write

    

    I assume the real IP address is not needed for troubleshooting,
    replaced in red letters.

    

    There is repeated ebtries in /usr/afs/logs/FileLog:

    =====

    Mon Jul 16 15:29:21 2012 VL_RegisterAddrs rpc failed; will retry
    periodically (code=5389, err=0)

    Mon Jul 16 15:34:21 2012 VL_RegisterAddrs rpc failed; will retry
    periodically (code=5389, err=0)

    Mon Jul 16 15:39:21 2012 VL_RegisterAddrs rpc failed; will retry
    periodically (code=5389, err=0)

    =====

    

    Thank you very much.

    Qing

    

      

    

  


--------------060208020906070109070609--

From adeason@sinenomine.net  Mon Jul 16 23:02:43 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Mon, 16 Jul 2012 17:02:43 -0500
Subject: [OpenAFS] Re: bos backupsys silently failing for one or two volumes?
References: <584987D9-F7A1-4FE2-91D9-6D2A1A09413F@umich.edu>
Message-ID: <20120716170243.506047ca.adeason@sinenomine.net>

On Mon, 16 Jul 2012 15:07:10 -0400
Steve Simmons  wrote:

> Bos config for backupsys:
> 
>   bnode cron snapshot 1
>   parm /usr/sbin/vos backupsys -se localhost -localauth
>   parm 18:00
>   end

This may not be a 'silent' error; you're not recording the output.

> This particular volume came up on June 7. vos examine -fo verified the
> .backup being older than expected. We did a manual vos backup on it
> and was fine for a few days. It occurred again on the same value June
> 12, we did a manual backup again. On Jun 19 it hit again. This time we
> deliberately didn't do a manual backup, the next day it reported being
> an additional 24 hours out of date. We forced a backup. On Jun 22 it
> again reported being out of date, we let it go and it came up again on
> the 23rd. At that point we vos moved it from one partition to another
> on the same server, then back to the original partition. The next day,
> it once again had not gotten a .backup, but the next day it did
> (weekend). On July 5 it again had an old .backup. We then moved it to
> another server, and it has not yet thrown problems. We have had
> several other volumes generate similar errors, tho none this
> persistent.

When you manually issue a backup, are you running 'vos backup' ? Try
running 'vos backupsys' with the prefix set such that it only backs up
that one volume, and see if that makes a difference.

Alternatively, you can make the cron job save stdout/stderr somewhere,
and examine it after you notice that this has occurred.

-- 
Andrew Deason
adeason@sinenomine.net


From l.schimmer@cgv.tugraz.at  Tue Jul 17 12:51:41 2012
From: l.schimmer@cgv.tugraz.at (Lars Schimmer)
Date: Tue, 17 Jul 2012 13:51:41 +0200
Subject: [OpenAFS] Directories not reachable direct after creation - linux 1.6.1
Message-ID: <500551CD.1060402@cgv.tugraz.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I got a more or less peristant problem on my debian linux system with
OpenAFS 1.6.1 64bit:

127 schimmer@tetris /afs/.cgv.tugraz.at/archive/templates %  mkdir
TUGraz.Formulare

mkdir: kann Verzeichnis ?TUGraz.Formulare? nicht anlegen: Kein
passendes Ger=E4t gefunden

1 schimmer@tetris /afs/.cgv.tugraz.at/archive/templates % ls
cgv-coorperate-design/  cgv_logo/  FhG/  slides/  TUG_Logo/
Visitenkarten.tex*

schimmer@tetris /afs/.cgv.tugraz.at/archive/templates % fs exa .

File . (536871524.1.1) contained in volume 536871524
Volume status for vid =3D 536871524 named archive.templates
Current disk quota is 1024000
Current blocks used are 376072
The partition has 337817914 blocks available out of 1003206068

schimmer@tetris /afs/.cgv.tugraz.at/archive/templates % vos exa
archive.templates
archive.templates                 536871524 RW     376070 K  On-line
    deimos.cgv.tugraz.at /vicepr
    RWrite  536871524 ROnly  536871525 Backup  536871526
    MaxQuota    1024000 K
    Creation    Mon Oct 10 16:38:37 2005
    Copy        Wed May 30 16:45:33 2012
    Backup      Mon Jul 16 22:00:10 2012
    Last Access Tue Jul 17 13:37:58 2012
    Last Update Mon Jul  9 09:11:44 2012
    206 accesses in the past day (i.e., vnode references)

    RWrite: 536871524     ROnly: 536871525     Backup: 536871526
    number of sites -> 5
       server deimos.cgv.tugraz.at partition /vicepr RW Site
       server afsgraz.igd.fraunhofer.de partition /vicepa RO Site
       server deimos.cgv.tugraz.at partition /vicepr RO Site
       server trinculo.cgv.tugraz.at partition /vicepar RO Site
       server phobos.cgv.tugraz.at partition /vicepar RO Site
schimmer@tetris /afs/.cgv.tugraz.at/archive/templates % ls
cgv-coorperate-design/  cgv_logo/  FhG/  slides/  TUG_Logo/
Visitenkarten.tex*
schimmer@tetris /afs/.cgv.tugraz.at/archive/templates % fs getserverprefs
trinculo.cgv.tugraz.at                             20013
afsgraz.igd.fraunhofer.de                          40011
phobos.cgv.tugraz.at                               20014
deimos.cgv.tugraz.at                               20009

But on a different workstation:
larissa /afs/.cgv.tugraz.at/archive/templates # ls
cgv-coorperate-design/  cgv_logo/  FhG/  slides/  TUG_Logo/
TUGraz.Formulare/  Visitenkarten.tex*

So my OpenAFS does create a directory, but it cannot read it afterwards.
Same did happen with fs mkmount:

schimmer@tetris /afs/.cgv.tugraz.at/home % fs mkmount eg user.eg
fs:'eg': No such device

On the other workstation:
larissa /afs/.cgv.tugraz.at/home/eg # ls
bhampe/

That happend >2 hour ago and I still cannot reach that directory on my
workstation tetris. But on any other I can.
I work as admin and have the RW volume I do work in.

Any idea?

apt-cache policy openafs-client
openafs-client:
  Installiert: 1.6.1-1



MfG,
Lars Schimmer
- --=20
- -------------------------------------------------------------
TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723


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

iEYEARECAAYFAlAFUc0ACgkQmWhuE0qbFyPINACfc3aYCJ5hpT6micjZ8EXxfJm3
OhAAoIUoqIM+MBiIsIrtAnRqyyxhdO6z
=3DHT8L
-----END PGP SIGNATURE-----

From scs@umich.edu  Tue Jul 17 16:15:14 2012
From: scs@umich.edu (Steve Simmons)
Date: Tue, 17 Jul 2012 11:15:14 -0400
Subject: [OpenAFS] Re: bos backupsys silently failing for one or two volumes?
In-Reply-To: <20120716170243.506047ca.adeason@sinenomine.net>
References: <584987D9-F7A1-4FE2-91D9-6D2A1A09413F@umich.edu> <20120716170243.506047ca.adeason@sinenomine.net>
Message-ID: <6EC78788-0CE9-4368-A267-D7357CB241DC@umich.edu>

On Jul 16, 2012, at 6:02 PM, Andrew Deason wrote:

> On Mon, 16 Jul 2012 15:07:10 -0400
> Steve Simmons  wrote:
>=20
>> Bos config for backupsys:
>>=20
>>  bnode cron snapshot 1
>>  parm /usr/sbin/vos backupsys -se localhost -localauth
>>  parm 18:00
>>  end
>=20
> This may not be a 'silent' error; you're not recording the output.

Interesting. I'd assumed that since BosLog contains the nightly message =
'snapshot exited with code 0' that no error had occurred. I'll start =
capturing those if/when the issue arises again.

>=20
>> This particular volume came up on June 7 . . .
>=20
> When you manually issue a backup, are you running 'vos backup' ? Try
> running 'vos backupsys' with the prefix set such that it only backs up
> that one volume, and see if that makes a difference.

Yes we have, I'll try that next time the issue comes up.

Thanks for the suggestions.

Steve=

From adeason@sinenomine.net  Tue Jul 17 17:34:51 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Tue, 17 Jul 2012 11:34:51 -0500
Subject: [OpenAFS] Re: vos create fails with "no quorum elected"
References: <50042CF8.2040307@sri.utoronto.ca>
 <20120716143108.bd766bb3.adeason@sinenomine.net>
 <50046F13.4040002@sri.utoronto.ca>
Message-ID: <20120717113451.ad2c2e92.adeason@sinenomine.net>

[sorry for delays, I am rather busy]

On Mon, 16 Jul 2012 15:44:19 -0400
Qing Chang  wrote:

> [root@smb1 logs]# udebug  smb1 7003 -long
> Host's addresses are: (smb1's IP)
> Host's(smb1's IP) time is Mon Jul 16 15:37:57 2012
> Local time is Mon Jul 16 15:37:58 2012 (time differential 1 secs)
> Last yes vote not cast yet
> Local db version is 1342191857.6
> I am sync site forever (0 server)
> Recovery state 0

So, the vlserver thinks you have 0 servers in your cell. That's
peculiar. What is in your /usr/afs/etc/CellServDB? This is your
server-side CellServDB, which is different than the client-side
CellServDB in /usr/vice/etc/CellServDB.

In the quick start guide, this should have been configured around the
'Defining Cell Name and Membership for Server Processes' step.

-- 
Andrew Deason
adeason@sinenomine.net


From qchang@sri.utoronto.ca  Wed Jul 18 15:13:41 2012
From: qchang@sri.utoronto.ca (Qing Chang)
Date: Wed, 18 Jul 2012 10:13:41 -0400
Subject: [OpenAFS] Re: vos create fails with "no quorum elected"
In-Reply-To: <20120717113451.ad2c2e92.adeason@sinenomine.net>
References: <50042CF8.2040307@sri.utoronto.ca> <20120716143108.bd766bb3.adeason@sinenomine.net> <50046F13.4040002@sri.utoronto.ca> <20120717113451.ad2c2e92.adeason@sinenomine.net>
Message-ID: <5006C495.5090901@sri.utoronto.ca>

This is a multi-part message in MIME format.
--------------050203010702050601090309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 17/07/2012 12:34 PM, Andrew Deason wrote:
> [sorry for delays, I am rather busy]
>
> On Mon, 16 Jul 2012 15:44:19 -0400
> Qing Chang  wrote:
>
>> [root@smb1 logs]# udebug  smb1 7003 -long
>> Host's addresses are: (smb1's IP)
>> Host's(smb1's IP) time is Mon Jul 16 15:37:57 2012
>> Local time is Mon Jul 16 15:37:58 2012 (time differential 1 secs)
>> Last yes vote not cast yet
>> Local db version is 1342191857.6
>> I am sync site forever (0 server)
>> Recovery state 0
> So, the vlserver thinks you have 0 servers in your cell. That's
> peculiar. What is in your /usr/afs/etc/CellServDB? This is your
> server-side CellServDB, which is different than the client-side
> CellServDB in /usr/vice/etc/CellServDB.
[root@smb1 logs]# cat /usr/afs/etc/CellServDB
 >openafs.sri.utoronto.ca        #Cell name
142.76.x.x    #smb1.sri.utoronto.ca
[root@smb1 logs]# cat /usr/vice/etc/CellServDB
 >openafs.sri.utoronto.ca        #Cell name
142.76.x.x    #smb1.sri.utoronto.ca
> In the quick start guide, this should have been configured around the
> 'Defining Cell Name and Membership for Server Processes' step.
>
I think I followed the instruction by running this:

*bos setcellname*      *-noauth
*

I may have done something wrong with the client side stuff, I did not remove
the symlink in /usr/vice/etc that point to CellDBServ and ThisCell in
/usr/afs/etc. I have removed them now.

Thanks,
Qing

--------------050203010702050601090309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    On 17/07/2012 12:34 PM, Andrew Deason wrote:
    

      
[sorry for delays, I am rather busy]

On Mon, 16 Jul 2012 15:44:19 -0400
Qing Chang <qchang@sri.utoronto.ca> wrote:



      

        
[root@smb1 logs]# udebug  smb1 7003 -long
Host's addresses are: (smb1's IP)
Host's(smb1's IP) time is Mon Jul 16 15:37:57 2012
Local time is Mon Jul 16 15:37:58 2012 (time differential 1 secs)
Last yes vote not cast yet
Local db version is 1342191857.6
I am sync site forever (0 server)
Recovery state 0


      

      
So, the vlserver thinks you have 0 servers in your cell. That's
peculiar. What is in your /usr/afs/etc/CellServDB? This is your
server-side CellServDB, which is different than the client-side
CellServDB in /usr/vice/etc/CellServDB.


    

    [root@smb1 logs]# cat /usr/afs/etc/CellServDB

    >openafs.sri.utoronto.ca        #Cell name

    142.76.x.x    #smb1.sri.utoronto.ca

    [root@smb1 logs]# cat /usr/vice/etc/CellServDB

    >openafs.sri.utoronto.ca        #Cell name

    142.76.x.x    #smb1.sri.utoronto.ca

    

      
In the quick start guide, this should have been configured around the
'Defining Cell Name and Membership for Server Processes' step.



    

    I think I followed the instruction by running this:

    
bos setcellname <machine name> <cell name> -noauth



    I may have done something wrong with the client side stuff, I did
    not remove

    the symlink in /usr/vice/etc that point to CellDBServ and ThisCell
    in 

    /usr/afs/etc. I have removed them now.

    

    Thanks,

    Qing

  


--------------050203010702050601090309--

From adeason@sinenomine.net  Wed Jul 18 16:10:21 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Wed, 18 Jul 2012 10:10:21 -0500
Subject: [OpenAFS] Re: vos create fails with "no quorum elected"
References: <50042CF8.2040307@sri.utoronto.ca>
 <20120716143108.bd766bb3.adeason@sinenomine.net>
 <50046F13.4040002@sri.utoronto.ca>
 <20120717113451.ad2c2e92.adeason@sinenomine.net>
 <5006C495.5090901@sri.utoronto.ca>
Message-ID: <20120718101021.4365152e.adeason@sinenomine.net>

On Wed, 18 Jul 2012 10:13:41 -0400
Qing Chang  wrote:

> [root@smb1 logs]# cat /usr/afs/etc/CellServDB
>  >openafs.sri.utoronto.ca        #Cell name

Hm, and I assume /usr/afs/etc/ThisCell has 'openafs.sri.utoronto.ca' in
it, correct?

Can you provide the output of 'bos listhosts ' ? If you restart
the server processes and run that 'udebug' command again, does it still
say 'I am sync site forever (0 server)'?

-- 
Andrew Deason
adeason@sinenomine.net


From gsomlo@gmail.com  Wed Jul 18 17:06:24 2012
From: gsomlo@gmail.com (Gabriel L. Somlo)
Date: Wed, 18 Jul 2012 12:06:24 -0400
Subject: [OpenAFS] OS X Lion: multiple Kerberos realms ?
Message-ID: <20120718160624.GB29562@hedwig.ini.cmu.edu>

Hi,

I have the same username in two different Kerberos realms. One realm
authenticates the OpenAFS cell I am trying to use. The other realm
authenticats a Samba server from which I'm also trying to map shares.

Without loss of generality, I could be attempting to use AFS home
directories in two separate cells backed by separate kerberos realms,
in which I happen to have the same user name.

I managed to automatically acquire Kerberos tickets on login to Lion,
using this method:

Start /System/Library/CoreServices/Directory Utility;
Pick the "Directory Editor" tab
Under "users", find the appropriate user account
Under "AuthenticationAuthority", add a line:

	;Kerberosv5;;user@REALM1.EXAMPLE.COM;REALM1.EXAMPLE.COM


This gets me tickets for user@REALM1; but if I add two lines, one for
each of user@REALM1 and user@REALM2, I only get tickets for the first
listed realm, and not for the second one (both work if they're either
first or the only one listed).

Any OSX/Lion experts out there who know how to force acquisition of
Kerb tickets from more than one realm upon login ?

Thanks,
--Gabriel

From jaltman@secure-endpoints.com  Wed Jul 18 17:13:58 2012
From: jaltman@secure-endpoints.com (Jeffrey Altman)
Date: Wed, 18 Jul 2012 12:13:58 -0400
Subject: [OpenAFS] OS X Lion: multiple Kerberos realms ?
In-Reply-To: <20120718160624.GB29562@hedwig.ini.cmu.edu>
References: <20120718160624.GB29562@hedwig.ini.cmu.edu>
Message-ID: <5006E0C6.2060207@secure-endpoints.com>

Why are you using two Kerberos realms in this scenario?
I recommend that you add an afs service principal to the Samba realm and
use that to authenticate your users to both services.

At the very least, use cross-realm authentication between the realms and
keep all of the users in the Samba realm and leave the afs service 
principal
in the other.

If you are using separate Kerberos realms, be sure to use separate DNS
subdomains for the hosts that are authenticated by each.

Jeffrey Altman

On Wednesday, July 18, 2012 12:06:24 PM, Gabriel L. Somlo wrote:
> Hi,
>
> I have the same username in two different Kerberos realms. One realm
> authenticates the OpenAFS cell I am trying to use. The other realm
> authenticats a Samba server from which I'm also trying to map shares.
>
> Without loss of generality, I could be attempting to use AFS home
> directories in two separate cells backed by separate kerberos realms,
> in which I happen to have the same user name.
>
> I managed to automatically acquire Kerberos tickets on login to Lion,
> using this method:
>
> Start /System/Library/CoreServices/Directory Utility;
> Pick the "Directory Editor" tab
> Under "users", find the appropriate user account
> Under "AuthenticationAuthority", add a line:
>
> 	;Kerberosv5;;user@REALM1.EXAMPLE.COM;REALM1.EXAMPLE.COM
>
>
> This gets me tickets for user@REALM1; but if I add two lines, one for
> each of user@REALM1 and user@REALM2, I only get tickets for the first
> listed realm, and not for the second one (both work if they're either
> first or the only one listed).
>
> Any OSX/Lion experts out there who know how to force acquisition of
> Kerb tickets from more than one realm upon login ?
>
> Thanks,
> --Gabriel
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info


From gsomlo@gmail.com  Wed Jul 18 17:45:48 2012
From: gsomlo@gmail.com (Gabriel L. Somlo)
Date: Wed, 18 Jul 2012 12:45:48 -0400
Subject: [OpenAFS] OS X Lion: multiple Kerberos realms ?
In-Reply-To: <5006E0C6.2060207@secure-endpoints.com>
References: <20120718160624.GB29562@hedwig.ini.cmu.edu>
 <5006E0C6.2060207@secure-endpoints.com>
Message-ID: <20120718164548.GC29562@hedwig.ini.cmu.edu>

On Wed, Jul 18, 2012 at 12:13:58PM -0400, Jeffrey Altman wrote:
> Why are you using two Kerberos realms in this scenario?
> I recommend that you add an afs service principal to the Samba realm and
> use that to authenticate your users to both services.

The two servers are under the control of different entities, and I
have no significant influence over either.

I can easily (via kinit, or the Ticket Viewer) acquire tickets for any
number of realms I need, but I'd like to take advantage of my common
user name and password across both realms to automate this process
during login...

Thanks,
--Gabriel

From allbery.b@gmail.com  Wed Jul 18 17:55:13 2012
From: allbery.b@gmail.com (Brandon Allbery)
Date: Wed, 18 Jul 2012 12:55:13 -0400
Subject: [OpenAFS] OS X Lion: multiple Kerberos realms ?
In-Reply-To: <20120718164548.GC29562@hedwig.ini.cmu.edu>
References: <20120718160624.GB29562@hedwig.ini.cmu.edu>
 <5006E0C6.2060207@secure-endpoints.com>
 <20120718164548.GC29562@hedwig.ini.cmu.edu>
Message-ID: 

--f46d0444ea81d5c7e604c51d8696
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 18, 2012 at 12:45 PM, Gabriel L. Somlo  wrote:

> I can easily (via kinit, or the Ticket Viewer) acquire tickets for any
>

Via kinit?  Really?

Kerberos doesn't really have a good way t deal with multiple realms.
 Apple's modified Kerberos tries to work around this (so it *does* sort of
work from Ticket Viewer) but the standard Kerberos APIs don't provide ways
to specify the realm credentials to use.  This means (a) not much if any
support from login, and (b) programs like Samba and OpenAFS can only see
the currently selected credentials in Ticket Viewer, not all of them.

I will also note that this would only work "well" at login if you used the
same password in both realms, which is a very bad idea and possibly a
security violation.

-- 
brandon s allbery                                      allbery.b@gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

--f46d0444ea81d5c7e604c51d8696
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Jul 18, 2012 at 12:45 PM, Gabriel L. Somlo <gsomlo=
@gmail.com> wrote:


I can easily (via kinit, or the Ticket Viewer) acquire ti=
ckets for any



Via kinit? =C2=A0Really?

Kerberos doesn't really have a good way t deal with multiple re=
alms. =C2=A0Apple's modified Kerberos tries to work around this (so it =
*does* sort of work from Ticket Viewer) but the standard Kerberos APIs don&=
#39;t provide ways to specify the realm credentials to use. =C2=A0This mean=
s (a) not much if any support from login, and (b) programs like Samba and O=
penAFS can only see the currently selected credentials in Ticket Viewer, no=
t all of them.



I will also note that this would only work "well&q=
uot; at login if you used the same password in both realms, which is a very=
 bad idea and possibly a security violation.


-- 
brandon s allbery =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0allbery.=
b@gmail.com
wandering unix systems administrator (available) =C2=A0 =
=C2=A0 (412) 475-9364 vm/sms






--f46d0444ea81d5c7e604c51d8696--

From gsomlo@gmail.com  Wed Jul 18 18:25:11 2012
From: gsomlo@gmail.com (Gabriel L. Somlo)
Date: Wed, 18 Jul 2012 13:25:11 -0400
Subject: [OpenAFS] OS X Lion: multiple Kerberos realms ?
In-Reply-To: 
References: <20120718160624.GB29562@hedwig.ini.cmu.edu>
 <5006E0C6.2060207@secure-endpoints.com>
 <20120718164548.GC29562@hedwig.ini.cmu.edu>
 
Message-ID: <20120718172510.GD29562@hedwig.ini.cmu.edu>

On Wed, Jul 18, 2012 at 12:55:13PM -0400, Brandon Allbery wrote:
> On Wed, Jul 18, 2012 at 12:45 PM, Gabriel L. Somlo  wrote:
> 
> > I can easily (via kinit, or the Ticket Viewer) acquire tickets for any
> >
> 
> Via kinit?  Really?

Heh, yeah. Not knowing it's "not supposed to" work, I tried, and I got
tickets for both realms to show up in the viewer. True, klist will
only show one (whichever was acquired last), but once I have the
tickets, I can map Samba shares and work in AFS simultaneously,
without any apparent problems.

> Kerberos doesn't really have a good way t deal with multiple realms.
>  Apple's modified Kerberos tries to work around this (so it *does* sort of
> work from Ticket Viewer) but the standard Kerberos APIs don't provide ways
> to specify the realm credentials to use.  This means (a) not much if any
> support from login, and (b) programs like Samba and OpenAFS can only see
> the currently selected credentials in Ticket Viewer, not all of them.

OK, so I'm obviously trying to work around a political problem with
technology, which usually involves a fair amount of pain :) I can buy
(a) above -- I didn't know that, and it was basically my original
question if/how I can get that to work. However, (b) seems to work just
fine.

> I will also note that this would only work "well" at login if you used the
> same password in both realms, which is a very bad idea and possibly a
> security violation.

OK, to provide an explanation for this: there's a Unix Kerberos realm,
and an AD one within the same org. The passwords are synchronized
across the two realms (for that old "single-sign-on" feeling). It's
easy (and supported) to join a Samba server to the AD domain (and
require users to have AD kerb tickets to map shares). It's not easy
to get a cifs service principal from the Unix Kerberos side
(organizationally speaking, not talking about the technical act of
generating the service principal).

The path of least resistance appeared to be to acquire two sets of
tickets and move on, except now you're telling me that it's a mere
accident it even works to begin with, forget about automating it at
login :)

I guess the currently available solution is to either

	1. work a political miracle and get a Unix kerberos
	   service principal for Samba, then use just the Unix
	   realm.

or

	2. pick a realm (either AD or Unix) to authenticate against
	   at login, and leave users with having to enter their
	   password again whenever they attempt to connect to AFS or
	   Samba, respectively (whichever service authenticated by the
	   *other* realm)

Obviously, the technically sound way would be #1 (which is what Jeffrey
also suggested), but I was hoping I can avoid an (unfortunately much more
likely) #2...

Thanks,
--Gabriel

From kenh@cmf.nrl.navy.mil  Wed Jul 18 18:48:16 2012
From: kenh@cmf.nrl.navy.mil (Ken Hornstein)
Date: Wed, 18 Jul 2012 13:48:16 -0400
Subject: [OpenAFS] OS X Lion: multiple Kerberos realms ?
In-Reply-To: <20120718172510.GD29562@hedwig.ini.cmu.edu>
Message-ID: <201207181748.q6IHmG6e021442@hedwig.cmf.nrl.navy.mil>

>Heh, yeah. Not knowing it's "not supposed to" work, I tried, and I got
>tickets for both realms to show up in the viewer. True, klist will
>only show one (whichever was acquired last), but once I have the
>tickets, I can map Samba shares and work in AFS simultaneously,
>without any apparent problems.

That it "works" at all is due to Apple-specific magic; I suspect
if you do "klist -A" it will show both sets of credentials.  You can
use kswitch to switch between the credentials, but there's really only
one active at a time (AFS continues to work even if you switch away
from the cache with the AFS credentials, because AFS stores the service
ticket itself).

I don't have a good solution to your problem, unfortunately.

--Ken

From adeason@sinenomine.net  Wed Jul 18 18:50:15 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Wed, 18 Jul 2012 12:50:15 -0500
Subject: [OpenAFS] Re: OS X Lion: multiple Kerberos realms ?
References: <20120718160624.GB29562@hedwig.ini.cmu.edu>
 <5006E0C6.2060207@secure-endpoints.com>
 <20120718164548.GC29562@hedwig.ini.cmu.edu>
 
 <20120718172510.GD29562@hedwig.ini.cmu.edu>
Message-ID: <20120718125015.c5c51bc1.adeason@sinenomine.net>

On Wed, 18 Jul 2012 13:25:11 -0400
"Gabriel L. Somlo"  wrote:

> I guess the currently available solution is to either
> 
>
> 	1. work a political miracle and get a Unix kerberos
> 	   service principal for Samba, then use just the Unix
> 	   realm.

If I'm understanding your scenario right, I think you are missing two
other options:

3. Create an AFS service principal in the AD realm.

4. Create a cross-realm trust between the two realms. The AFS service
principal lives in the Unix realm, and the users get tickets for AD.

Both of these let you authenticate to AFS while having tickets only for
AD.

-- 
Andrew Deason
adeason@sinenomine.net


From njriley@illinois.edu  Wed Jul 18 18:47:19 2012
From: njriley@illinois.edu (Nicholas Riley)
Date: Wed, 18 Jul 2012 13:47:19 -0400
Subject: [OpenAFS] Re: OS X Lion: multiple Kerberos realms ?
References: <20120718160624.GB29562@hedwig.ini.cmu.edu> <5006E0C6.2060207@secure-endpoints.com> <20120718164548.GC29562@hedwig.ini.cmu.edu>  <20120718172510.GD29562@hedwig.ini.cmu.edu>
Message-ID: 

In article <20120718172510.GD29562@hedwig.ini.cmu.edu>,
 "Gabriel L. Somlo"  wrote:

> Heh, yeah. Not knowing it's "not supposed to" work, I tried, and I got
> tickets for both realms to show up in the viewer. True, klist will
> only show one (whichever was acquired last), but once I have the
> tickets, I can map Samba shares and work in AFS simultaneously,
> without any apparent problems.

You can use kswitch to switch credentials caches without using Ticket 
Viewer.  You don't need to know the name of the credential cache, just 
use kswitch -p , or on 10.7, kswitch -i will give you a list 
to pick from.
-- 
Nicholas Riley 


From jaltman@your-file-system.com  Wed Jul 18 20:56:05 2012
From: jaltman@your-file-system.com (Jeffrey Altman)
Date: Wed, 18 Jul 2012 15:56:05 -0400
Subject: [OpenAFS] Seeking testers: Windows 7vs OpenAFS 1.6.x (SMB interface)
Message-ID: <500714D5.8090904@your-file-system.com>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig15952CD775E818A3A1F57E04
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If you are still using OpenAFS 1.6.x on Windows and are reliably able to
reproduce the condition where connectivity with \\AFS is lost until the
system is rebooted, I am in search of volunteers to test a hot fix
candidate.  If testing is successful, Microsoft will publish a hot fix
that permits the SMB redirector to reliably work with the OpenAFS SMB
server.

Requirements:

 * Must be running either Windows 7 or Windows 7 SP1 (X86 or X64)

 * Must be able to reliably reproduce the loss of connectivity

 * Must be able to run your system in test signing mode.  This mode disab=
les
   the checks to ensure that Microsoft Windows binaries are digitally sig=
ned
   by the official Microsoft Windows certificate chain.

 * Must be able to install Microsoft Network Monitor 3.4

 * Must be willing to collect runtime data for sharing with Your File Sys=
tem
   and Microsoft staff.

If you meet these criteria, and wish to assist with testing, please send =
me
private e-mail.  Do not reply to the mailing list.

Thank you.

Jeffrey Altman



--------------enig15952CD775E818A3A1F57E04
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQBxTXAAoJENxm1CNJffh4sG0H/3PtA5rgXKxpKU/8nJPtvAGs
e21vR9m24x36IjMV08QvTEUVLELd04MwbQsRF8G7QVy9oryvcIi4Iaw+GNgMBTX9
Jh4U2MiMjUjRz2/WQu0Baj3LTQjpWQXqQXJGJwnjl2C0965RZX1ZywTITkCn/50M
/cbX/7io5qJE7F2OrbmYN3P/TGObfYJKjEA3XGZoyaWSXepFK/cYOjqr+uoK+ect
TThg7dZ3C7lrjTGCA+pqdms4fTjDbgs5jbN8M1owswwcLkwuJ91y01b+Tz1J3QAc
/i9fie1hyIRdsbEybyUvkoLcn/ofzdJGCA6O9NHuRX114h1+okObrbWMJ0hDM/c=
=okAc
-----END PGP SIGNATURE-----

--------------enig15952CD775E818A3A1F57E04--


From qchang@sri.utoronto.ca  Wed Jul 18 21:54:27 2012
From: qchang@sri.utoronto.ca (Qing Chang)
Date: Wed, 18 Jul 2012 16:54:27 -0400
Subject: [OpenAFS] Re: vos create fails with "no quorum elected"
In-Reply-To: <20120718101021.4365152e.adeason@sinenomine.net>
References: <50042CF8.2040307@sri.utoronto.ca> <20120716143108.bd766bb3.adeason@sinenomine.net> <50046F13.4040002@sri.utoronto.ca> <20120717113451.ad2c2e92.adeason@sinenomine.net> <5006C495.5090901@sri.utoronto.ca> <20120718101021.4365152e.adeason@sinenomine.net>
Message-ID: <50072283.3030606@sri.utoronto.ca>


On 18/07/2012 11:10 AM, Andrew Deason wrote:
> On Wed, 18 Jul 2012 10:13:41 -0400
> Qing Chang  wrote:
>
>> [root@smb1 logs]# cat /usr/afs/etc/CellServDB
>>   >openafs.sri.utoronto.ca        #Cell name
> Hm, and I assume /usr/afs/etc/ThisCell has 'openafs.sri.utoronto.ca' in
> it, correct?
yes
> Can you provide the output of 'bos listhosts' ? If you restart
> the server processes and run that 'udebug' command again, does it still
> say 'I am sync site forever (0 server)'?
>
After a reboot, everything looks OK, strange:
[root@smb1 ~]#  udebug  smb1 7003 -long
Host's addresses are: 142.76.x.x
Host's 142.76.x.x time is Wed Jul 18 11:20:12 2012
Local time is Wed Jul 18 11:20:13 2012 (time differential 1 secs)
Last yes vote for x.x.76.142 was 0 secs ago (sync site);
Last vote started 0 secs ago (at Wed Jul 18 11:20:13 2012)
Local db version is 1342622470.2
I am sync site forever (1 server)
Recovery state 1f
The last trans I handled was 1342622470.2
Sync site's db version is 1342622470.2
0 locked pages, 0 of them for write
Last time a new db version was labelled was:
          2342 secs ago (at Wed Jul 18 10:41:11 2012)

The command runs successfully:
[root@smb1 ~]# vos create smb1 /vicepa  afsdoc  -maxquota  0
Volume 536870918 created on partition /vicepa of smb1

Thanks,
Qing

From haba@kth.se  Thu Jul 19 09:50:45 2012
From: haba@kth.se (Harald Barth)
Date: Thu, 19 Jul 2012 10:50:45 +0200 (CEST)
Subject: [OpenAFS] Re: OS X Lion: multiple Kerberos realms ?
In-Reply-To: <20120718125015.c5c51bc1.adeason@sinenomine.net>
References: 
 <20120718172510.GD29562@hedwig.ini.cmu.edu>
 <20120718125015.c5c51bc1.adeason@sinenomine.net>
Message-ID: <20120719.105045.367096801094862616.haba@habanero>

>> 	1. work a political miracle and get a Unix kerberos
>> 	   service principal for Samba, then use just the Unix
>> 	   realm.
> 
> If I'm understanding your scenario right, I think you are missing two
> other options:
> 
> 3. Create an AFS service principal in the AD realm.
> 
> 4. Create a cross-realm trust between the two realms. The AFS service
> principal lives in the Unix realm, and the users get tickets for AD.
> 
> Both of these let you authenticate to AFS while having tickets only for
> AD.

As we have the same situation at KTH that the keeper of the AD will not
do such things unless pigz fliez, I understand Gabriel's problem. I have
been juggling with small scripts that do set KRB5CCNAME, then authenticate
without afslog and then afslog to a specific cell in that tokens context
for years. But it still fails in situations where a program expects to
have its credentials in a single KRB5CCNAME like thunderbird towards
different realms.

So what tools do we have for "alien" multi realm scenarios?

Harald.

From florianr@uni-paderborn.de  Thu Jul 19 21:39:32 2012
From: florianr@uni-paderborn.de (Florian Rittmeier)
Date: Thu, 19 Jul 2012 22:39:32 +0200
Subject: [OpenAFS] Adobe Reader X and OpenAFS 1.7.15
Message-ID: <50087084.4000808@uni-paderborn.de>

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms030004050507070202020109
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Hello,

multiple users had a somewhat strange experience with Adobe Reader X and =

OpenAFS 1.7.15. They opened a PDF downloaded from a webserver and wanted =

to save it under a new name on a afs share (network drive letter=20
mapping). From Adobe Reader X perspective this works fine so the user=20
believes, that everything worked as expected. Unfortunately when=20
checking the folder on the afs share the file is not there. As we had=20
this problem at multiple machines with different users I would like to=20
know wether someone has experienced something similar.

We are running OpenAFS 1.7.15 on Windows 7 SP1 64-bit machines.

WIth kindly regards,
Florian


--------------ms030004050507070202020109
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Kryptografische Unterschrift

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO6jCC
BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK
ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy
MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa
Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw
DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U
1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6
fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869
080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD
oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh
nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov
L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy
bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/
6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX
3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR
M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba
hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ
hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH
xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFTjCCBDagAwIBAgIEC4nvvjAN
BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G
A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X
DTA3MTIyMDEzNDYyNFoXDTE5MDYzMDAwMDAwMFowgb4xCzAJBgNVBAYTAkRFMR8wHQYDVQQK
ExZVbml2ZXJzaXRhZXQgUGFkZXJib3JuMUAwPgYDVQQLEzdJTVQgKFplbnRydW0gZnVlciBJ
bmZvcm1hdGlvbnMtIHVuZCBNZWRpZW50ZWNobm9sb2dpZW4pMSgwJgYDVQQDEx9Vbml2ZXJz
aXRhZXQgUGFkZXJib3JuIENBIC0gRzAxMSIwIAYJKoZIhvcNAQkBFhNjYUB1bmktcGFkZXJi
b3JuLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApyEfhJPUiCaLTtclTNlw
rHd4MT4ygOzcUD7zDRElXdILoAEQeUs9qpMZDpPXLeSK6DNukMnURrCRUIr+lYX/kmT6ompB
GMJgDepewHa97XS3uvE46NW2V8OdIiNddYIoDa8ZRd9lwIsnVWl9QaM9f7l5dhrSQT6ogboy
byOqJcmb+hlxgQcMWdLzZsOXRkldl5YXUCvC6zbulszlqMt5hPjsQmbQu0nInJmNwUrYCw9c
ctS2i0m9LaVwZxSov16/eQAJOM7bDV9CpZicgCkHACP5paKvlukP9glkvfNdS54grkPmGFNp
uIc13W6pL1+8nTp03AlyW/GU2zsnX5pWdwIDAQABo4IBtTCCAbEwEgYDVR0TAQH/BAgwBgEB
/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFIHPTJq8rw/LvuzgIidOKe+uMMUeMB8GA1Ud
IwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB4GA1UdEQQXMBWBE2NhQHVuaS1wYWRlcmJv
cm4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2Jh
bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCB
kjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w
dWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4u
ZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUA
A4IBAQAaomheE7QGeiZFxhmjRI97H/eQUUjp2RL2N4BQmulz56nwTFfgGN1v9kJmBuM2se7F
TSfQ0ZsKYJhZYwZYCb4Ob57h5zpsyMtZhWqz6n5+ewT/Wl7jc6sLGl3zquMZRfS1N3nIOWsN
rAZz4lxpjcOJwQHQevWpJT2NxTHHtHKA83QWLFAFs65ZIVAVxqYlRd9Yrr/ljK42ZzEaZgg8
vSqDzHOwvWX5m3apWe3ZW+2eqjDGZxwfWnWBMSGYN0QIFdaZLR1JbILLfYYHyAUixHUFA+76
2E9gufC2CySlXhNSPRTwqwPQIDTFDi2VIsafaivs7kVKPaKSq1Dh6SDfV2raMIIFbzCCBFeg
AwIBAgIEEHD8MTANBgkqhkiG9w0BAQUFADCBvjELMAkGA1UEBhMCREUxHzAdBgNVBAoTFlVu
aXZlcnNpdGFldCBQYWRlcmJvcm4xQDA+BgNVBAsTN0lNVCAoWmVudHJ1bSBmdWVyIEluZm9y
bWF0aW9ucy0gdW5kIE1lZGllbnRlY2hub2xvZ2llbikxKDAmBgNVBAMTH1VuaXZlcnNpdGFl
dCBQYWRlcmJvcm4gQ0EgLSBHMDExIjAgBgkqhkiG9w0BCQEWE2NhQHVuaS1wYWRlcmJvcm4u
ZGUwHhcNMTAwNzI5MTMxNDA5WhcNMTMwNzI4MTMxNDA5WjBKMQswCQYDVQQGEwJERTEfMB0G
A1UEChMWVW5pdmVyc2l0YWV0IFBhZGVyYm9ybjEaMBgGA1UEAxMRRmxvcmlhbiBSaXR0bWVp
ZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBGc8iEaltQN0rbLZJnsdn0Mr+
yNqdmeDC7TRMGA9hxfN9sQ2tddkqqUabdqyJHnPj0fevEgOWCVBVtWvL1GTL6YxrkTFL+odY
pLmdIKQPfpU+9tZqiSqLaEjkrWTbczobSrT4BUZ4ujkUqj7s+kpz/oKiExoMLJy9X+Xu1Bux
aj4zJ3TJsio6I8Eqx0jZcDz9myC2wMH1rrN1BV09lV6soldQmOgk2siOOqAgcMNKg+nvl2BZ
NNe3LVci8h+XKauirllfSAuJ976FyJku5Ce9Gz8QaWTY5eXZrkwLelFe2Ajb+ZvE7fsQxVEu
fgQoV4D/NvFrFlPlpbQib9K+GSbTAgMBAAGjggHmMIIB4jAJBgNVHRMEAjAAMAsGA1UdDwQE
AwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0O
BBYEFFmzrmGMk9Xrn26oXexENrjcEgmyMB8GA1UdIwQYMBaAFIHPTJq8rw/LvuzgIidOKe+u
MMUeMCQGA1UdEQQdMBuBGWZsb3JpYW5yQHVuaS1wYWRlcmJvcm4uZGUwgY0GA1UdHwSBhTCB
gjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktcGFkZXJib3JuLWNhL3B1Yi9j
cmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1wYWRlcmJv
cm4tY2EvcHViL2NybC9jYWNybC5jcmwwgaYGCCsGAQUFBwEBBIGZMIGWMEkGCCsGAQUFBzAC
hj1odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1wYWRlcmJvcm4tY2EvcHViL2NhY2VydC9j
YWNlcnQuY3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1wYWRl
cmJvcm4tY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQAKz/Gw
G3ofcNyv6rY/8V6Mi4n4LmseB785vtVuFGFgI3ilVkeQ+Q4l36Cj4kKqjpDpV2iRI+JksCF2
y0MzQX2+NuQ9Ry1XJ1jQz8LWw47hjcRhhm42xfg2ci/iFRN55js9bpuPDCdwAAaK7hD8SJJQ
QPR0ww3+XOxrtAJIpLAlExN0V/CsybIQCyODLjJc7IEJtLYc2xsaL0yEsliId0kJ66ijOeUt
3AkKGMgvsmVfufAv/MgIgBZ1G1mpZ3aN9aGOOo8VDfp4t3NRTlHNyTsTqMV5rw7pSxP2sDgT
4g0MB2I6nLjJii+I1FrSupovxxYeV0CNnjxyIn6cb3TCUc90MYIEdjCCBHICAQEwgccwgb4x
CzAJBgNVBAYTAkRFMR8wHQYDVQQKExZVbml2ZXJzaXRhZXQgUGFkZXJib3JuMUAwPgYDVQQL
EzdJTVQgKFplbnRydW0gZnVlciBJbmZvcm1hdGlvbnMtIHVuZCBNZWRpZW50ZWNobm9sb2dp
ZW4pMSgwJgYDVQQDEx9Vbml2ZXJzaXRhZXQgUGFkZXJib3JuIENBIC0gRzAxMSIwIAYJKoZI
hvcNAQkBFhNjYUB1bmktcGFkZXJib3JuLmRlAgQQcPwxMAkGBSsOAwIaBQCgggKDMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxOTIwMzkzMlowIwYJ
KoZIhvcNAQkEMRYEFMY57qJIgMNwkYmwqJ7sOp0v2WUSMGwGCSqGSIb3DQEJDzFfMF0wCwYJ
YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdgGCSsGAQQBgjcQBDGByjCB
xzCBvjELMAkGA1UEBhMCREUxHzAdBgNVBAoTFlVuaXZlcnNpdGFldCBQYWRlcmJvcm4xQDA+
BgNVBAsTN0lNVCAoWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0gdW5kIE1lZGllbnRlY2hu
b2xvZ2llbikxKDAmBgNVBAMTH1VuaXZlcnNpdGFldCBQYWRlcmJvcm4gQ0EgLSBHMDExIjAg
BgkqhkiG9w0BCQEWE2NhQHVuaS1wYWRlcmJvcm4uZGUCBBBw/DEwgdoGCyqGSIb3DQEJEAIL
MYHKoIHHMIG+MQswCQYDVQQGEwJERTEfMB0GA1UEChMWVW5pdmVyc2l0YWV0IFBhZGVyYm9y
bjFAMD4GA1UECxM3SU1UIChaZW50cnVtIGZ1ZXIgSW5mb3JtYXRpb25zLSB1bmQgTWVkaWVu
dGVjaG5vbG9naWVuKTEoMCYGA1UEAxMfVW5pdmVyc2l0YWV0IFBhZGVyYm9ybiBDQSAtIEcw
MTEiMCAGCSqGSIb3DQEJARYTY2FAdW5pLXBhZGVyYm9ybi5kZQIEEHD8MTANBgkqhkiG9w0B
AQEFAASCAQCuLk7MTUYORXWD0m2HLX3SKU4+mkbYhHrqvCYCAXf/xn2Gpce08MxJUiWu8LIT
Es/znCNZp1ZMu4gIu/U+uE4/GhJHjCK2bJgluvaUhE0ffjTRrmjQDM211BBlYqtg9JGoxmxp
uIU3TTyRlvZrac4+VD1wGP/opXO+hslqhtG+we3SAMjcQ+zUxeI0nrNbbkbFnGWRFRUO+Gtv
2xzAnSeAIWKAMuuOYPtTq+ijVs9LueP1+KGdcVMORDpv+81xyKD/d7Bczku3jYC3B3JQxkjF
9gOjr42TuLaoXYNZA9wOyAZvIbnklPr31mpTON+d/y8FySxLJv2UNykcrrdk0UqEAAAAAAAA

--------------ms030004050507070202020109--

From florianr@uni-paderborn.de  Fri Jul 20 11:26:34 2012
From: florianr@uni-paderborn.de (Florian Rittmeier)
Date: Fri, 20 Jul 2012 12:26:34 +0200
Subject: [OpenAFS] Adobe Reader X and OpenAFS 1.7.15
In-Reply-To: <50087084.4000808@uni-paderborn.de>
References: <50087084.4000808@uni-paderborn.de>
Message-ID: <5009325A.1060003@uni-paderborn.de>

Hello again,

I just found a ticket [1] which fits to the problem description, 
therefore my question is resolved.

Regards,
Florian

[1] http://rt.central.org/rt/Ticket/Display.html?id=130851


Am 19.07.2012 22:39, schrieb Florian Rittmeier:
> Hello,
>
> multiple users had a somewhat strange experience with Adobe Reader X 
> and OpenAFS 1.7.15. They opened a PDF downloaded from a webserver and 
> wanted to save it under a new name on a afs share (network drive 
> letter mapping). From Adobe Reader X perspective this works fine so 
> the user believes, that everything worked as expected. Unfortunately 
> when checking the folder on the afs share the file is not there. As we 
> had this problem at multiple machines with different users I would 
> like to know wether someone has experienced something similar.
>
> We are running OpenAFS 1.7.15 on Windows 7 SP1 64-bit machines.
>
> WIth kindly regards,
> Florian
>



From pontius@btv.ibm.com  Tue Jul 24 21:04:26 2012
From: pontius@btv.ibm.com (Dale Pontius)
Date: Tue, 24 Jul 2012 16:04:26 -0400
Subject: [OpenAFS] Has anyone built openafs-1.6.1 against linux kernel 3.5 yet?
Message-ID: <500EFFCA.5000306@btv.ibm.com>

I got the following messages:

/var/tmp/portage/net-fs/openafs-kernel-1.6.1/work/openafs-1.6.1/src/libafs/MODLOAD-3.5.0-gentoo-MP/osi_vfsops.c: 
In function ‘afs_evict_inode’:
/var/tmp/portage/net-fs/openafs-kernel-1.6.1/work/openafs-1.6.1/src/libafs/MODLOAD-3.5.0-gentoo-MP/osi_vfsops.c:287:5: 
error: implicit declaration of function ‘end_writeback’
make[6]: *** 
[/var/tmp/portage/net-fs/openafs-kernel-1.6.1/work/openafs-1.6.1/src/libafs/MODLOAD-3.5.0-gentoo-MP/osi_vfsops.o] 
Error 1
make[5]: *** 
[_module_/var/tmp/portage/net-fs/openafs-kernel-1.6.1/work/openafs-1.6.1/src/libafs/MODLOAD-3.5.0-gentoo-MP] 
Error 2
make[5]: Leaving directory `/usr/src/linux-3.5.0-gentoo'
make[4]: *** [libafs.ko] Error 2
make[4]: Leaving directory 
`/var/tmp/portage/net-fs/openafs-kernel-1.6.1/work/openafs-1.6.1/src/libafs/MODLOAD-3.5.0-gentoo-MP'
make[3]: *** [linux_compdirs] Error 2
make[3]: Leaving directory 
`/var/tmp/portage/net-fs/openafs-kernel-1.6.1/work/openafs-1.6.1/src/libafs'
make[2]: *** [libafs] Error 2
make[2]: Leaving directory 
`/var/tmp/portage/net-fs/openafs-kernel-1.6.1/work/openafs-1.6.1'
make[1]: *** [build] Error 2
make[1]: Leaving directory 
`/var/tmp/portage/net-fs/openafs-kernel-1.6.1/work/openafs-1.6.1'
make: *** [only_libafs] Error 2
emake failed

This is running Gentoo Linux, mostly stable. Thanks.

-- 
Dale Pontius
Senior Engineer
IBM Corporation
Phone: (802) 769-6850
Tie-Line: 446-6850
email: pontius@us.ibm.com

This e-mail and its attachments, if any, may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message from your system without copying it and notify sender of the misdirection by reply e-mail.


From adeason@sinenomine.net  Tue Jul 24 22:44:19 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Tue, 24 Jul 2012 16:44:19 -0500
Subject: [OpenAFS] Re: Has anyone built openafs-1.6.1 against linux kernel 3.5 yet?
References: <500EFFCA.5000306@btv.ibm.com>
Message-ID: <20120724164419.6b90d198.adeason@sinenomine.net>

On Tue, 24 Jul 2012 16:04:26 -0400
Dale Pontius  wrote:

> Subject: Has anyone built openafs-1.6.1 against linux kernel 3.5 yet?

Not successfully, I'm sure, considering OpenAFS 1.6.1 was released
way before linux 3.5 :)

I expect the following patches would help:




Or you could just try the head of the 1.6 branch.

-- 
Andrew Deason
adeason@sinenomine.net


From gautraut@in.ibm.com  Wed Jul 25 12:59:44 2012
From: gautraut@in.ibm.com (Gautam U Raut)
Date: Wed, 25 Jul 2012 17:29:44 +0530
Subject: [OpenAFS] How to setup Heimdal Kerberos 5 for OpenAFS 1.7.15 Client on Windows 7
Message-ID: 

Hi All,

I hope this is a right forum for discussing below mentioned problem.

I have a Windows 7 x64 bit client machine and a valid KDC.
I have been provided a username and password for that KDC.
I have installed OpenAFS 1.7.15 client on this my client machine
along with Heimdal 1.5.

I want to use Heimdal Kerberos 5 with this OpenAFS installation.

I have configured krb5.conf as:

[libdefaults]
	default_realm = NAME_OF_REALM
	allow_weak_crypto = true
	clockskew = 300

[realms]
	NAME_OF_REALM = {
		kdc = valid_DNS_name.DNS.com:88
		admin_server = valid_DNS_name.DNS.com:749
	}

[domain_realm]
	.DNS.com = NAME_OF_REALM
	DNS.com = NAME_OF_REALM

Now what other steps I need to do in order to get things working.

Regards,
Gautam


From Sergio.Gelato@astro.su.se  Wed Jul 25 22:40:03 2012
From: Sergio.Gelato@astro.su.se (Sergio Gelato)
Date: Wed, 25 Jul 2012 23:40:03 +0200
Subject: [OpenAFS] How to setup Heimdal Kerberos 5 for OpenAFS 1.7.15
 Client on Windows 7
In-Reply-To: 
References: 
Message-ID: <20120725214001.GA7302@hanuman.astro.su.se>

* Gautam U Raut [2012-07-25 17:29:44 +0530]:
> I have a Windows 7 x64 bit client machine and a valid KDC.
> I have been provided a username and password for that KDC.
> I have installed OpenAFS 1.7.15 client on this my client machine
> along with Heimdal 1.5.

How about also installing Network Identity Manager 2.0 (hereafter NetIdMgr)?
Available from https://www.secure-endpoints.com/ (which may well be the same 
place you got Heimdal from).

> Now what other steps I need to do in order to get things working.

What is it exactly that doesn't work? You should be able to browse
portions of several cells (e.g., openafs.org) unauthenticated through
\\AFS\all\; this requires neither Heimdal nor NetIdMgr.
And once you've got all of Heimdal, NetIdMgr and OpenAFS you should be
able to use NetIdMgr to obtain a TGT for your realm and an AFS service
ticket/token for your cell; the latter might give you access to more of
the data stored in your cell, depending on what the ACLs look like.

(I assume that your AFS cell is already set up.)

From gautraut@in.ibm.com  Thu Jul 26 07:37:50 2012
From: gautraut@in.ibm.com (Gautam U Raut)
Date: Thu, 26 Jul 2012 12:07:50 +0530
Subject: [OpenAFS] How to setup Heimdal Kerberos 5 for OpenAFS 1.7.15 Client on
 Windows 7
In-Reply-To: <20120725214001.GA7302@hanuman.astro.su.se>
References:  <20120725214001.GA7302@hanuman.astro.su.se>
Message-ID: 

I agree that Network Identity Manager is useful here.

>>What is it exactly that doesn't work?
I want to create a installation script which will
execute sequentially and prompt user for required inputs and
setup OpenAFS client with Keberos 5 support.

This script will allow me to automate setup activity,
and create a uniform setup across multiple client
machines in future.

Regards,
Gautam



                                                                           
             Sergio Gelato                                                 
                                                              To 
             Sent by:                  Gautam U Raut/India/IBM@IBMIN       
             openafs-info-admi                                          cc 
             n@openafs.org             openafs-info                        
                                                 
                                                                   Subject 
             07/26/2012 03:10          Re: [OpenAFS] How to setup Heimdal  
             AM                        Kerberos 5 for OpenAFS 1.7.15       
                                       Client on Windows 7                 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




* Gautam U Raut [2012-07-25 17:29:44 +0530]:
> I have a Windows 7 x64 bit client machine and a valid KDC.
> I have been provided a username and password for that KDC.
> I have installed OpenAFS 1.7.15 client on this my client machine
> along with Heimdal 1.5.

How about also installing Network Identity Manager 2.0 (hereafter
NetIdMgr)?
Available from https://www.secure-endpoints.com/ (which may well be the
same
place you got Heimdal from).

> Now what other steps I need to do in order to get things working.

What is it exactly that doesn't work? You should be able to browse
portions of several cells (e.g., openafs.org) unauthenticated through
\\AFS\all\; this requires neither Heimdal nor NetIdMgr.
And once you've got all of Heimdal, NetIdMgr and OpenAFS you should be
able to use NetIdMgr to obtain a TGT for your realm and an AFS service
ticket/token for your cell; the latter might give you access to more of
the data stored in your cell, depending on what the ACLs look like.

(I assume that your AFS cell is already set up.)
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info




From youssefeldakar@gmail.com  Thu Jul 26 12:22:25 2012
From: youssefeldakar@gmail.com (Youssef Eldakar)
Date: Thu, 26 Jul 2012 14:22:25 +0300
Subject: [OpenAFS] Transferring data from old server to new server
Message-ID: 

--f46d042f9bf063617504c5b9cf29
Content-Type: text/plain; charset=ISO-8859-1

1.4.12+dfsg-3+ubuntu0.1. I am planning to replace this OpenAFS server with
another one on another machine running Ubuntu 12.04, which comes with
OpenAFS version 1.6.1-1. What's the simplest way to transfer the data over
to the new server? Would just rsyncing /vicepa work?

Thank you for advising.

--f46d042f9bf063617504c5b9cf29
Content-Type: text/html; charset=ISO-8859-1


1.4.12+dfsg-3+ubuntu0.1. I am planning to replace this OpenAFS server 
with another one on another machine running Ubuntu 12.04, which comes 
with OpenAFS version 1.6.1-1. What's the simplest way to transfer the 
data over to the new server? Would just rsyncing /vicepa work?


Thank you for advising.


--f46d042f9bf063617504c5b9cf29--

From l.schimmer@cgv.tugraz.at  Thu Jul 26 13:03:53 2012
From: l.schimmer@cgv.tugraz.at (Lars Schimmer)
Date: Thu, 26 Jul 2012 14:03:53 +0200
Subject: [OpenAFS] Transferring data from old server to new server
In-Reply-To: 
References: 
Message-ID: <50113229.7080504@cgv.tugraz.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-07-26 13:22, Youssef Eldakar wrote:
> 1.4.12+dfsg-3+ubuntu0.1. I am planning to replace this OpenAFS=20
> server with another one on another machine running Ubuntu 12.04,=20
> which comes with OpenAFS version 1.6.1-1. What's the simplest way=20
> to transfer the data over to the new server? Would just rsyncing=20
> /vicepa work?

Do you really want to replace the hardware?
If not, just upgrading is a solution (at least for the fileserver, the
DB server(s) do have some special limitations).

If you really want to have new hardware and new fileserver, is it
possible to run both the same time and vos move the volume from old
server to the new one?

> Thank you for advising.


MfG,
Lars Schimmer
- --=20
- -------------------------------------------------------------
TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723


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

iEYEARECAAYFAlARMigACgkQmWhuE0qbFyNQyQCcDLOUZA8g5/HTTaZJ+spXb5kB
e+sAn198qp+ok5MxI/X2FJ0PR5b60pSB
=3Da1vh
-----END PGP SIGNATURE-----

From adeason@sinenomine.net  Thu Jul 26 15:41:03 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Thu, 26 Jul 2012 09:41:03 -0500
Subject: [OpenAFS] Re: Transferring data from old server to new server
References: 
Message-ID: <20120726094103.9975c3e9.adeason@sinenomine.net>

On Thu, 26 Jul 2012 14:22:25 +0300
Youssef Eldakar  wrote:

> 1.4.12+dfsg-3+ubuntu0.1. I am planning to replace this OpenAFS server
> with another one on another machine running Ubuntu 12.04, which comes
> with OpenAFS version 1.6.1-1. What's the simplest way to transfer the
> data over to the new server? Would just rsyncing /vicepa work?

As Lars mentions, using 'vos move' is often the "best" way; the way most
likely to not have problems. If you 'vos move' all of the data, make
sure to keep the old server on for at least 2 hours after everything has
moved before turning it off, so clients have a chance to notice that
their data has moved.

If you cannot or do not want to do that, yes, you can just rsync the
/vicep* directories (make sure you use -a). If you do that, you will
also want to sync the /var/lib/openafs/local directory (do _not_ do this
if you 'vos move' the data instead).

-- 
Andrew Deason
adeason@sinenomine.net


From tcreedon@easystreet.net  Thu Jul 26 16:53:21 2012
From: tcreedon@easystreet.net (Ted Creedon)
Date: Thu, 26 Jul 2012 08:53:21 -0700
Subject: [OpenAFS] Transferring data from old server to new server
In-Reply-To: 
References: 
Message-ID: 

--f46d043894ad54d29604c5bd98b1
Content-Type: text/plain; charset=ISO-8859-1

I have /usr/vice and /usr/afs on raid cards

I just unplug the card & move it and the drives to the new box.

ted

On Thu, Jul 26, 2012 at 4:22 AM, Youssef Eldakar
wrote:

> 1.4.12+dfsg-3+ubuntu0.1. I am planning to replace this OpenAFS server with
> another one on another machine running Ubuntu 12.04, which comes with
> OpenAFS version 1.6.1-1. What's the simplest way to transfer the data over
> to the new server? Would just rsyncing /vicepa work?
>
> Thank you for advising.
>

--f46d043894ad54d29604c5bd98b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have /usr/vice and /usr/afs on raid cards

I just unplug the card &=
amp; move it and the drives to the new box.

ted

On Thu, Jul 26, 2012 at 4:22 AM, Youssef Eldakar <you=
ssefeldakar@gmail.com> wrote:


1.4.12+dfsg-3+ubuntu0.1. I =
am planning to replace this OpenAFS server=20
with another one on another machine running Ubuntu 12.04, which comes=20
with OpenAFS version 1.6.1-1. What's the simplest way to transfer the=
=20
data over to the new server? Would just rsyncing /vicepa work?


Thank you for advising.





--f46d043894ad54d29604c5bd98b1--

From adeason@sinenomine.net  Thu Jul 26 20:30:19 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Thu, 26 Jul 2012 14:30:19 -0500
Subject: [OpenAFS] Re: Directories not reachable direct after creation - linux 1.6.1
References: <500551CD.1060402@cgv.tugraz.at>
Message-ID: <20120726143019.3866d1f0.adeason@sinenomine.net>

On Tue, 17 Jul 2012 13:51:41 +0200
Lars Schimmer  wrote:

> I got a more or less peristant problem on my debian linux system with
> OpenAFS 1.6.1 64bit:
> 
> 127 schimmer@tetris /afs/.cgv.tugraz.at/archive/templates %  mkdir
> TUGraz.Formulare
> 
> mkdir: kann Verzeichnis ?TUGraz.Formulare? nicht anlegen: Kein
> passendes Gerät gefunden

I assume 'No such device' is a suitable English translation for this,
yes? Does this take a while (at least a few seconds) to execute?

I also assume that the specified name did not already exist (as a dir,
or file, or mountpoint, or anything).

> Any idea?

If there were any messages in the client syslog or the server FileLog at
around the same time, that information would be helpful.

1.6.1 should contain the client behavior where we invalidate cache
information for a timed-out write op, so it's probably not just that
(although it's not perfect). If you can get this to happen while
'fstrace' tracing is on, that should say exactly what was going on at
the time. (Something like: fstrace clear cm ; fstrace setlog cmfx
-buffers 100 ; fstrace sets cm -active ; mkdir whatever & echo $! ; wait
; fstrace dump cm > /tmp/fstrace.log ; fstrace sets cm -inactive) Note
that that traces all client activity, so if you've got other
AFS-interacting stuff running on the box that you don't want to be
public information, don't upload that somewhere public.

And it doesn't really "solve" the problem, but if you see a client in
that state, you may be able to get it out with a 'fs flush .' in the
problematic directory (or 'fs flushv' to just flush everyting in the
vol). 'fs checks' and 'fs checkv' can also be tried, though it doesn't
seem like that would be the problem here.

-- 
Andrew Deason
adeason@sinenomine.net


From jwedgeco@uncc.edu  Thu Jul 26 21:48:31 2012
From: jwedgeco@uncc.edu (Edgecombe, Jason)
Date: Thu, 26 Jul 2012 20:48:31 +0000
Subject: [OpenAFS] Best practice for cleaning up PTS groups after users are deleted
Message-ID: <4DE25DED585CD840A23808AFDE3DA2064226C0@RPITSEXMS1.its.uncc.edu>

--_004_4DE25DED585CD840A23808AFDE3DA2064226C0RPITSEXMS1itsuncc_
Content-Type: multipart/alternative;
	boundary="_000_4DE25DED585CD840A23808AFDE3DA2064226C0RPITSEXMS1itsuncc_"

--_000_4DE25DED585CD840A23808AFDE3DA2064226C0RPITSEXMS1itsuncc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

How do other sites deal with groups after users are deleted? How do you exp=
ire groups that own other groups? Are there pre-existing scripts for doing =
this?

Thanks,
Jason

---------------------------------------------------------------------------
Jason Edgecombe | Linux and Solaris Administrator
UNC Charlotte | The William States Lee College of Engineering
9201 University City Blvd. | Charlotte, NC 28223-0001
Phone: 704-687-3514
jwedgeco@uncc.edu | http://coe.uncc.edu | [Description: facebook-logo]   Facebook
---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person resp=
onsible for delivering it to the intended recipient, any disclosure, copyin=
g, distribution, or other use of any of the information in this transmissio=
n is strictly prohibited. If you have received this transmission in error, =
please notify me immediately by reply e-mail or by telephone at 704-687-351=
4.  Thank you.


--_000_4DE25DED585CD840A23808AFDE3DA2064226C0RPITSEXMS1itsuncc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi everyone,


 


How do other sites deal with groups after users are =
deleted? How do you expire groups that own other groups? Are there pre-exis=
ting scripts for doing this?


 


Thanks,


Jason


 


------------------------------------------=
---------------------------------


Jason Edgeco=
mbe
| Linux and Solaris Administrator


UNC Charlott=
e
| The William States Lee College of Engineering

9201 Univers=
ity City Blvd.
| Charlotte, NC 28223-0001


Phone: 704-6=
87-3514


jwedgeco@uncc.edu=

| http:/=
/coe.uncc.edu |
3D"Desc= Facebook<=
/span>


------------=
---------------------------------------------------------------<=
/span>


If you are n=
ot the intended recipient of this transmission or a person responsible for =
delivering it to the intended recipient, any disclosure, copying,
 distribution, or other use of any of the information in this transmission =
is strictly prohibited. If you have received this transmission in error, pl=
ease notify me immediately by reply e-mail or by telephone at 704-687-3514.=
  Thank you.


 






--_000_4DE25DED585CD840A23808AFDE3DA2064226C0RPITSEXMS1itsuncc_--

--_004_4DE25DED585CD840A23808AFDE3DA2064226C0RPITSEXMS1itsuncc_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=367;
	creation-date="Thu, 26 Jul 2012 20:47:08 GMT";
	modification-date="Thu, 26 Jul 2012 20:47:08 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhEAAQANUAAE1rpUJfkipGhzVRkU5omGmDt+3v80Vfn/P0+D5YmElioWh/tDBLjDpVllJp
mTZSknuNuU5mlUxmpDNPkH2TwEFcmyxJiX6QvVBop9vh69zh61NwplZzqE1uqUpsqEZpplRzrVd1
rn6UwVp4sEBko1p9skNnpVBxq1hwrF16siRBf1R1rP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAQABAAAAaMQMQF
RSwaiRcEZEEROZ9QygKCKaSu2Oy1gJGMvmAwh0D4ShShtDq90bBYacUBRK/TM28W/VA5+f9+b4AV
CR2GhwEBb4mGCQ0ekJF5eZANDx+YmZNvmA8TJqChoG+iEwwkqKmob6oMFiWwsbBvshYCACu5uitv
ugACDgO4u7wsuQADDgYRKs3Oz80RBkEAOw==

--_004_4DE25DED585CD840A23808AFDE3DA2064226C0RPITSEXMS1itsuncc_--

From jaltman@secure-endpoints.com  Thu Jul 26 22:56:41 2012
From: jaltman@secure-endpoints.com (Jeffrey Altman)
Date: Thu, 26 Jul 2012 17:56:41 -0400
Subject: [OpenAFS] Best practice for cleaning up PTS groups after users
 are deleted
In-Reply-To: <4DE25DED585CD840A23808AFDE3DA2064226C0@RPITSEXMS1.its.uncc.edu>
References: <4DE25DED585CD840A23808AFDE3DA2064226C0@RPITSEXMS1.its.uncc.edu>
Message-ID: <5011BD19.7010805@secure-endpoints.com>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD0A034A054018A759347F2CF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A security best practice is to never delete users and groups because=20
you don't know what ACLs they might be listed on.
The same is true for Kerberos principal names.  You can disable the=20
issuance of tickets but do not remove them from the database.


On Thursday, July 26, 2012 4:48:31 PM, Edgecombe, Jason wrote:
> Hi everyone,
>
>
>
> How do other sites deal with groups after users are deleted? How do
> you expire groups that own other groups? Are there pre-existing
> scripts for doing this?
>
>
>
> Thanks,
>
> Jason
>
>
>
> -----------------------------------------------------------------------=
----
>
> Jason Edgecombe *| *Linux and Solaris Administrator
>
> UNC Charlotte *| *The William States Lee College of Engineering
>
> 9201 University City Blvd. *| *Charlotte, NC 28223-0001
>
> Phone: 704-687-3514
>
> jwedgeco@uncc.edu  *| *http://coe.uncc.edu
>  | Description: facebook-logo
>  Facebook
> 
>
> -----------------------------------------------------------------------=
----
>
> If you are not the intended recipient of this transmission or a person
> responsible for delivering it to the intended recipient, any
> disclosure, copying, distribution, or other use of any of the
> information in this transmission is strictly prohibited. If you have
> received this transmission in error, please notify me immediately by
> reply e-mail or by telephone at 704-687-3514.  Thank you.
>
>
>


--------------enigD0A034A054018A759347F2CF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQEb0ZAAoJENxm1CNJffh4JMkIAOQT6v6spLeulz0wVattRu3l
BjkDU4Nl7df2bvxSiJZoQ42QjiNa2j5VIz5ePPuq0wUxIcTSxLDcVRRbYPMyFUiR
RdIncx5ezqgh0RzbovvlMPZQKelVwRlvyhWbEmjbw0BTQ5WEqlmUz28DfxdmBv8G
VzQ+cvHqY0vnNkN/RnQ+5szES9B34kj0pi5dVvFoTPZGYTxaaiOO1yiqRjiBqGHk
q7u+/55BcJr7nrjeriR29Zu2+dITEp1+YC34ioeEtEjQvNv4zeoJd/70tzcPv7GU
qsox6UpVubvz+spuR293oVB2NLCPR9ms0g2Y7g/qzOaf8JnmORB7lWpgWLxKG2U=
=UHD5
-----END PGP SIGNATURE-----

--------------enigD0A034A054018A759347F2CF--


From rra@stanford.edu  Thu Jul 26 23:10:45 2012
From: rra@stanford.edu (Russ Allbery)
Date: Thu, 26 Jul 2012 15:10:45 -0700
Subject: [OpenAFS] Best practice for cleaning up PTS groups after users are deleted
In-Reply-To: <5011BD19.7010805@secure-endpoints.com> (Jeffrey Altman's message
 of "Thu, 26 Jul 2012 17:56:41 -0400")
References: <4DE25DED585CD840A23808AFDE3DA2064226C0@RPITSEXMS1.its.uncc.edu>
 <5011BD19.7010805@secure-endpoints.com>
Message-ID: <87pq7ip40q.fsf@windlord.stanford.edu>

Jeffrey Altman  writes:

> A security best practice is to never delete users and groups because you
> don't know what ACLs they might be listed on.  The same is true for
> Kerberos principal names.  You can disable the issuance of tickets but
> do not remove them from the database.

I prefer deleting them and then running fs cleanacl across the entire cell
on a time period faster than reuse of the same PTS ID.

-- 
Russ Allbery (rra@stanford.edu)             

From jason@rampaginggeek.com  Thu Jul 26 23:30:20 2012
From: jason@rampaginggeek.com (Jason Edgecombe)
Date: Thu, 26 Jul 2012 18:30:20 -0400
Subject: [OpenAFS] Best practice for cleaning up PTS groups after users
 are deleted
In-Reply-To: <87pq7ip40q.fsf@windlord.stanford.edu>
References: <4DE25DED585CD840A23808AFDE3DA2064226C0@RPITSEXMS1.its.uncc.edu> <5011BD19.7010805@secure-endpoints.com> <87pq7ip40q.fsf@windlord.stanford.edu>
Message-ID: <5011C4FC.3020402@rampaginggeek.com>

On 07/26/2012 06:10 PM, Russ Allbery wrote:
> Jeffrey Altman  writes:
>
>> A security best practice is to never delete users and groups because you
>> don't know what ACLs they might be listed on.  The same is true for
>> Kerberos principal names.  You can disable the issuance of tickets but
>> do not remove them from the database.
> I prefer deleting them and then running fs cleanacl across the entire cell
> on a time period faster than reuse of the same PTS ID.
>
We delete users and run fs cleanacl. I'm trying to figure out how to 
properly clean up the groups. What criteria do other sites use for 
removing groups. I know about orphaned gruops, but I'm looking for good 
advice about self-owning groups and groups owned by other groups.

Thanks,
Jason

From rra@stanford.edu  Thu Jul 26 23:53:52 2012
From: rra@stanford.edu (Russ Allbery)
Date: Thu, 26 Jul 2012 15:53:52 -0700
Subject: [OpenAFS] Best practice for cleaning up PTS groups after users are deleted
In-Reply-To: <5011C4FC.3020402@rampaginggeek.com> (Jason Edgecombe's message
 of "Thu, 26 Jul 2012 18:30:20 -0400")
References: <4DE25DED585CD840A23808AFDE3DA2064226C0@RPITSEXMS1.its.uncc.edu>
 <5011BD19.7010805@secure-endpoints.com>
 <87pq7ip40q.fsf@windlord.stanford.edu>
 <5011C4FC.3020402@rampaginggeek.com>
Message-ID: <87394ecewu.fsf@windlord.stanford.edu>

Jason Edgecombe  writes:

> We delete users and run fs cleanacl. I'm trying to figure out how to
> properly clean up the groups. What criteria do other sites use for
> removing groups. I know about orphaned gruops, but I'm looking for good
> advice about self-owning groups and groups owned by other groups.

Nearly all of our groups are tied to specific things with a lifecycle,
like group spaces in AFS, and are therefore deleted alongside that space
when that space is deleted.

We don't otherwise do anything comprehensive.

-- 
Russ Allbery (rra@stanford.edu)             

From jason@rampaginggeek.com  Fri Jul 27 00:58:24 2012
From: jason@rampaginggeek.com (Jason Edgecombe)
Date: Thu, 26 Jul 2012 19:58:24 -0400
Subject: [OpenAFS] Best practice for cleaning up PTS groups after users
 are deleted
In-Reply-To: <87394ecewu.fsf@windlord.stanford.edu>
References: <4DE25DED585CD840A23808AFDE3DA2064226C0@RPITSEXMS1.its.uncc.edu> <5011BD19.7010805@secure-endpoints.com> <87pq7ip40q.fsf@windlord.stanford.edu> <5011C4FC.3020402@rampaginggeek.com> <87394ecewu.fsf@windlord.stanford.edu>
Message-ID: <5011D9A0.107@rampaginggeek.com>

On 07/26/2012 06:53 PM, Russ Allbery wrote:
> Jason Edgecombe  writes:
>
>> We delete users and run fs cleanacl. I'm trying to figure out how to
>> properly clean up the groups. What criteria do other sites use for
>> removing groups. I know about orphaned gruops, but I'm looking for good
>> advice about self-owning groups and groups owned by other groups.
> Nearly all of our groups are tied to specific things with a lifecycle,
> like group spaces in AFS, and are therefore deleted alongside that space
> when that space is deleted.
>
> We don't otherwise do anything comprehensive.
>
What do you do with user-created groups?

Can you share the system that does the life-cycle stuff?

Thanks,
Jason

From rra@stanford.edu  Fri Jul 27 01:07:22 2012
From: rra@stanford.edu (Russ Allbery)
Date: Thu, 26 Jul 2012 17:07:22 -0700
Subject: [OpenAFS] Best practice for cleaning up PTS groups after users are deleted
In-Reply-To: <5011D9A0.107@rampaginggeek.com> (Jason Edgecombe's message of
 "Thu, 26 Jul 2012 19:58:24 -0400")
References: <4DE25DED585CD840A23808AFDE3DA2064226C0@RPITSEXMS1.its.uncc.edu>
 <5011BD19.7010805@secure-endpoints.com>
 <87pq7ip40q.fsf@windlord.stanford.edu>
 <5011C4FC.3020402@rampaginggeek.com>
 <87394ecewu.fsf@windlord.stanford.edu>
 <5011D9A0.107@rampaginggeek.com>
Message-ID: <87txwu9idh.fsf@windlord.stanford.edu>

Jason Edgecombe  writes:

> What do you do with user-created groups?

Ignore them, currently.

> Can you share the system that does the life-cycle stuff?

Unfortunately, no; it's got tentacles all over the place, is partly
manual, and relies on a whole bunch of internal infrastructure.

-- 
Russ Allbery (rra@stanford.edu)             

From l.schimmer@cgv.tugraz.at  Fri Jul 27 10:00:55 2012
From: l.schimmer@cgv.tugraz.at (Lars Schimmer)
Date: Fri, 27 Jul 2012 11:00:55 +0200
Subject: [OpenAFS] Re: Directories not reachable direct after creation
 - linux 1.6.1
In-Reply-To: <20120726143019.3866d1f0.adeason@sinenomine.net>
References: <500551CD.1060402@cgv.tugraz.at> <20120726143019.3866d1f0.adeason@sinenomine.net>
Message-ID: <501258C7.9090801@cgv.tugraz.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-07-26 21:30, Andrew Deason wrote:
> On Tue, 17 Jul 2012 13:51:41 +0200 Lars Schimmer
>  wrote:
>=20
>> I got a more or less peristant problem on my debian linux system
>> with OpenAFS 1.6.1 64bit:
>>=20
>> 127 schimmer@tetris /afs/.cgv.tugraz.at/archive/templates %
>> mkdir TUGraz.Formulare
>>=20
>> mkdir: kann Verzeichnis ?TUGraz.Formulare? nicht anlegen: Kein=20
>> passendes Ger=C3=A4t gefunden
>=20
> I assume 'No such device' is a suitable English translation for
> this, yes? Does this take a while (at least a few seconds) to
> execute?

Correct and correct.

> I also assume that the specified name did not already exist (as a
> dir, or file, or mountpoint, or anything).

Correct. All new.

>> Any idea?
>=20
> If there were any messages in the client syslog or the server
> FileLog at around the same time, that information would be
> helpful.

Ok, will see on new event... Does happen from time to time.

> 1.6.1 should contain the client behavior where we invalidate cache=20
> information for a timed-out write op, so it's probably not just
> that (although it's not perfect). If you can get this to happen
> while 'fstrace' tracing is on, that should say exactly what was
> going on at the time. (Something like: fstrace clear cm ; fstrace
> setlog cmfx -buffers 100 ; fstrace sets cm -active ; mkdir whatever
> & echo $! ; wait ; fstrace dump cm > /tmp/fstrace.log ; fstrace
> sets cm -inactive) Note that that traces all client activity, so if
> you've got other AFS-interacting stuff running on the box that you
> don't want to be public information, don't upload that somewhere
> public.
>=20
> And it doesn't really "solve" the problem, but if you see a client
> in that state, you may be able to get it out with a 'fs flush .' in
> the problematic directory (or 'fs flushv' to just flush everyting
> in the vol). 'fs checks' and 'fs checkv' can also be tried, though
> it doesn't seem like that would be the problem here.

I will see at next event.


MfG,
Lars Schimmer
- --=20
- -------------------------------------------------------------
TU Graz, Institut f=C3=BCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723


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

iEYEARECAAYFAlASWMcACgkQmWhuE0qbFyOdyQCeNUOIg7YUbYSJVneWKKgGtjp6
MG0AnjvcD6Z/wbEERLrLX1L81XyQIsYR
=3Dg6k4
-----END PGP SIGNATURE-----

From pontius@btv.ibm.com  Fri Jul 27 14:33:38 2012
From: pontius@btv.ibm.com (Dale Pontius)
Date: Fri, 27 Jul 2012 09:33:38 -0400
Subject: [OpenAFS] Re: Has anyone built openafs-1.6.1 against linux kernel
 3.5 yet?
In-Reply-To: <20120724164419.6b90d198.adeason@sinenomine.net>
References: <500EFFCA.5000306@btv.ibm.com> <20120724164419.6b90d198.adeason@sinenomine.net>
Message-ID: <501298B2.1050005@btv.ibm.com>

Those 2 patches appear to help.  The kernel module built, loaded, and 
survived brief testing.  I was also able to build the module against a 
3.4.4 kernel with the patched source, but haven't tested that yet.  On a 
different system I'd built the kernel module against a 3.4.5 kernel 
without patching, by the way.

More testing needed, but so far I see no problems.

Thanks,
Dale Pontius
On 07/24/2012 05:44 PM, Andrew Deason wrote:
> On Tue, 24 Jul 2012 16:04:26 -0400
> Dale Pontius  wrote:
>
>> Subject: Has anyone built openafs-1.6.1 against linux kernel 3.5 yet?
> Not successfully, I'm sure, considering OpenAFS 1.6.1 was released
> way before linux 3.5 :)
>
> I expect the following patches would help:
>
> 
> 
>
> Or you could just try the head of the 1.6 branch.
>

-- 
Dale Pontius
Senior Engineer
IBM Corporation
Phone: (802) 769-6850
Tie-Line: 446-6850
email: pontius@us.ibm.com

This e-mail and its attachments, if any, may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message from your system without copying it and notify sender of the misdirection by reply e-mail.


From youssefeldakar@gmail.com  Mon Jul 30 14:15:52 2012
From: youssefeldakar@gmail.com (Youssef Eldakar)
Date: Mon, 30 Jul 2012 16:15:52 +0300
Subject: [OpenAFS] Re: Transferring data from old server to new server
In-Reply-To: <20120726094103.9975c3e9.adeason@sinenomine.net>
References: 
 <20120726094103.9975c3e9.adeason@sinenomine.net>
Message-ID: 

--e89a8ff1c89e7d8d3e04c60bdcb1
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jul 26, 2012 at 4:41 PM, Andrew Deason wrote:

> On Thu, 26 Jul 2012 14:22:25 +0300
> Youssef Eldakar  wrote:
>
> > 1.4.12+dfsg-3+ubuntu0.1. I am planning to replace this OpenAFS server
> > with another one on another machine running Ubuntu 12.04, which comes
> > with OpenAFS version 1.6.1-1. What's the simplest way to transfer the
> > data over to the new server? Would just rsyncing /vicepa work?
>
> As Lars mentions, using 'vos move' is often the "best" way; the way most
> likely to not have problems. If you 'vos move' all of the data, make
> sure to keep the old server on for at least 2 hours after everything has
> moved before turning it off, so clients have a chance to notice that
> their data has moved.
>

Thanks for that advice.

>
> If you cannot or do not want to do that, yes, you can just rsync the
> /vicep* directories (make sure you use -a). If you do that, you will
> also want to sync the /var/lib/openafs/local directory (do _not_ do this
> if you 'vos move' the data instead).
>

And for this addition. It helps to know the transfer is also doable via
rsync.


>
> --
> Andrew Deason
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>

--e89a8ff1c89e7d8d3e04c60bdcb1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 26, 2012 at=
 4:41 PM, Andrew Deason <adeason@sinenomine.net> wrote:=



On Thu, 26 Jul 2012 14:22:25 +0300

Youssef Eldakar <youssefelda=
kar@gmail.com> wrote:



> 1.4.12+dfsg-3+ubuntu0.1. I am planning to replace this OpenAFS server<=
br>
> with another one on another machine running Ubuntu 12.04, which comes<=
br>
> with OpenAFS version 1.6.1-1. What's the simplest way to transfer =
the

> data over to the new server? Would just rsyncing /vicepa work?




As Lars mentions, using 'vos move' is often the "best&qu=
ot; way; the way most

likely to not have problems. If you 'vos move' all of the data, mak=
e

sure to keep the old server on for at least 2 hours after everything has
moved before turning it off, so clients have a chance to notice that

their data has moved.

Thanks for that advice. 
=




If you cannot or do not want to do that, yes, you can just rsync the

/vicep* directories (make sure you use -a). If you do that, you will

also want to sync the /var/lib/openafs/local directory (do _not_ do this
if you 'vos move' the data instead).

And f=
or this addition. It helps to know the transfer is also doable via rsync.=A0




--

Andrew Deason

adeason@sinenomine.net




_______________________________________________

OpenAFS-info mailing list

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





--e89a8ff1c89e7d8d3e04c60bdcb1--

From jaw171@pitt.edu  Mon Jul 30 18:46:10 2012
From: jaw171@pitt.edu (Jeff White)
Date: Mon, 30 Jul 2012 13:46:10 -0400
Subject: [OpenAFS] One DB server of three going offline kills 1.6 clients
 ("Waiting for busy volume")
Message-ID: <5016C862.8030507@pitt.edu>

I recently built two RHEL 6.3 x64 systems with 1.6.1-1 (compiled from 
the src.rpm) and they consistently have issues when one of our DB 
servers (running 1.2.11) is brought down for a cold backup of the AFS 
databases.  Our older clients (1.4.14.1-1 and below) do not have this issue.

We have three DB servers (afs09, afs10, afs11) with afs09 as the 
master.  Sunday at 4:05 AM a script run to stop the AFS DB processes on 
afs11 and tar the DB files then start the processes again.  When this 
happens our new 1.6.1 clients hang and begin spewing a large number of 
these errors:

Jul 29 04:00:27  ewi-afs-prod0 kernel: afs: Waiting for 
busy volume 1937412136 () in cell pitt.edu

Sometimes it is able to determine the volume name, sometimes not.  When 
this happen I cannot access anything in our AFS cell on the failing 
client, even after a reboot.  The one DB server is down only for a 
minute yet the issues continue after the DB server is back up.

So, a few questions:

Has anyone seen this behavior before when one DB server becomes 
inaccessible but other DB servers are available?
Is there anything I can do to troubleshoot the issue to help determine 
what is casing it?
If a client is talking to a particular DB server and the remote system 
stops responding, will the client silently move on to trying a different 
DB server or is it sticky to the same server and keep trying to talk to it?

I would hope that the last part of that is not true.  It should work 
like DNS by trying every DB server in sequence and only returning an 
error once all servers have failed.




Jul 29 04:22:31  ewi-afs-prod0 kernel: INFO: task httpd:1542 
blocked for more than 120 seconds.
Jul 29 04:22:31  ewi-afs-prod0 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 29 04:22:31  ewi-afs-prod0 kernel: httpd         D 
0000000000000000     0  1542   1535 0x00000080
Jul 29 04:22:31  ewi-afs-prod0 kernel:  ffff88013b8f3ba8 
0000000000000082 ffff88013b8f3c38 ffff880139bc1000
Jul 29 04:22:31  ewi-afs-prod0 kernel:  ffff88013b8f3b68 
ffffffffa02db742 ffff880137a9eae0 ffff880137a9eae0
Jul 29 04:22:31  ewi-afs-prod0 kernel:  ffff880137a9f098 
ffff88013b8f3fd8 000000000000fb88 ffff880137a9f098
Jul 29 04:22:31  ewi-afs-prod0 kernel: Call Trace:
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] ? afs_FindVCache+0xe2/0x5b0 [openafs]
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] __mutex_lock_slowpath+0x13e/0x180
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] ? afs_access+0x181/0x730 [openafs]
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] mutex_lock+0x2b/0x50
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] do_lookup+0x11b/0x230
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] __link_path_walk+0x20d/0x1030
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] ? perf_event_task_sched_out+0x33/0x80
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] path_walk+0x6a/0xe0
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] do_path_lookup+0x5b/0xa0
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] user_path_at+0x57/0xa0
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] ? unlink_anon_vmas+0x71/0xd0
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] vfs_fstatat+0x3c/0x80
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] vfs_stat+0x1b/0x20
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] sys_newstat+0x24/0x50
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] ? audit_syscall_entry+0x272/0x2a0
Jul 29 04:22:31  ewi-afs-prod0 kernel:  
[] system_call_fastpath+0x16/0x1b

-- 
Jeff White - GNU+Linux Systems Engineer
University of Pittsburgh - CSSD


From l.schimmer@cgv.tugraz.at  Tue Jul 31 10:50:12 2012
From: l.schimmer@cgv.tugraz.at (Lars Schimmer)
Date: Tue, 31 Jul 2012 11:50:12 +0200
Subject: [OpenAFS] Re: Directories not reachable direct after creation
 - linux 1.6.1 - FSTRACE available
In-Reply-To: <20120726143019.3866d1f0.adeason@sinenomine.net>
References: <500551CD.1060402@cgv.tugraz.at> <20120726143019.3866d1f0.adeason@sinenomine.net>
Message-ID: <5017AA54.9050504@cgv.tugraz.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-07-26 21:30, Andrew Deason wrote:

> I assume 'No such device' is a suitable English translation for
> this, yes? Does this take a while (at least a few seconds) to
> execute?

A few seconds.

> I also assume that the specified name did not already exist (as a
> dir, or file, or mountpoint, or anything).

No, complete new.

>> Any idea?

Got another incident:
fs mkmount extern user.extern
fs:'extern': No such device



> If there were any messages in the client syslog or the server
> FileLog at around the same time, that information would be
> helpful.

Ok, no entries syslog on local client, on fileserver only a line
Tue Jul 31 11:38:38 2012 1 Volser: CreateVolume: volume 1702200769
(user.extern) created

does appear aboiut this new volume.
It was in between a:
Tue Jul 31 11:37:14 2012 trans 23047 on volume 1702195000 is older
than 720 seconds
Tue Jul 31 11:37:44 2012 trans 23047 on volume 1702195000 is older
than 750 seconds
Tue Jul 31 11:38:14 2012 trans 23047 on volume 1702195000 is older
than 780 seconds
Tue Jul 31 11:38:38 2012 1 Volser: CreateVolume: volume 1702200769
(user.extern) created
Tue Jul 31 11:38:44 2012 trans 23047 on volume 1702195000 is older
than 810 seconds
Tue Jul 31 11:39:14 2012 trans 23047 on volume 1702195000 is older
than 840 seconds
Tue Jul 31 11:39:44 2012 trans 23047 on volume 1702195000 is older
than 870 seconds




> 1.6.1 should contain the client behavior where we invalidate cache=20
> information for a timed-out write op, so it's probably not just
> that (although it's not perfect). If you can get this to happen
> while 'fstrace' tracing is on, that should say exactly what was
> going on at the time. (Something like: fstrace clear cm ; fstrace
> setlog cmfx -buffers 100 ; fstrace sets cm -active ; mkdir whatever
> & echo $! ; wait ; fstrace dump cm > /tmp/fstrace.log ; fstrace
> sets cm -inactive) Note that that traces all client activity, so if
> you've got other AFS-interacting stuff running on the box that you
> don't want to be public information, don't upload that somewhere
> public.

Ok, fstrace made with that problem occuring:
http://tetris.cgv.tugraz.at/afs/fstrace.31.07.2012.txt

> And it doesn't really "solve" the problem, but if you see a client
> in that state, you may be able to get it out with a 'fs flush .' in
> the problematic directory (or 'fs flushv' to just flush everyting
> in the vol). 'fs checks' and 'fs checkv' can also be tried, though
> it doesn't seem like that would be the problem here.

A fs flush did not help.
A fs flushv did helped and I can access the new mounted volume.

MfG,
Lars Schimmer
- --=20
- -------------------------------------------------------------
TU Graz, Institut f=C3=BCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723


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

iEYEARECAAYFAlAXqlQACgkQmWhuE0qbFyOSngCdF2BYIyl3vdhSU2DMotZAK6OS
S5YAnjJ8kR1ZMF8ZyMOo3HssNF6gAjUS
=3DOmV9
-----END PGP SIGNATURE-----

From shadow@gmail.com  Tue Jul 31 14:23:52 2012
From: shadow@gmail.com (Derrick Brashear)
Date: Tue, 31 Jul 2012 09:23:52 -0400
Subject: [OpenAFS] Re: Directories not reachable direct after creation -
 linux 1.6.1 - FSTRACE available
In-Reply-To: <5017AA54.9050504@cgv.tugraz.at>
References: <500551CD.1060402@cgv.tugraz.at>
 <20120726143019.3866d1f0.adeason@sinenomine.net>
 <5017AA54.9050504@cgv.tugraz.at>
Message-ID: 

On Tue, Jul 31, 2012 at 5:50 AM, Lars Schimmer  w=
rote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2012-07-26 21:30, Andrew Deason wrote:
>
>> I assume 'No such device' is a suitable English translation for
>> this, yes? Does this take a while (at least a few seconds) to
>> execute?
>
> A few seconds.
>
>> I also assume that the specified name did not already exist (as a
>> dir, or file, or mountpoint, or anything).
>
> No, complete new.
>
>>> Any idea?
>
> Got another incident:
> fs mkmount extern user.extern
> fs:'extern': No such device
>
>
>
>> If there were any messages in the client syslog or the server
>> FileLog at around the same time, that information would be
>> helpful.
>
> Ok, no entries syslog on local client, on fileserver only a line
> Tue Jul 31 11:38:38 2012 1 Volser: CreateVolume: volume 1702200769
> (user.extern) created
>
> does appear aboiut this new volume.
> It was in between a:
> Tue Jul 31 11:37:14 2012 trans 23047 on volume 1702195000 is older
> than 720 seconds
> Tue Jul 31 11:37:44 2012 trans 23047 on volume 1702195000 is older
> than 750 seconds
> Tue Jul 31 11:38:14 2012 trans 23047 on volume 1702195000 is older
> than 780 seconds
> Tue Jul 31 11:38:38 2012 1 Volser: CreateVolume: volume 1702200769
> (user.extern) created
> Tue Jul 31 11:38:44 2012 trans 23047 on volume 1702195000 is older
> than 810 seconds
> Tue Jul 31 11:39:14 2012 trans 23047 on volume 1702195000 is older
> than 840 seconds
> Tue Jul 31 11:39:44 2012 trans 23047 on volume 1702195000 is older
> than 870 seconds
>
>
>
>
>> 1.6.1 should contain the client behavior where we invalidate cache
>> information for a timed-out write op, so it's probably not just
>> that (although it's not perfect). If you can get this to happen
>> while 'fstrace' tracing is on, that should say exactly what was
>> going on at the time. (Something like: fstrace clear cm ; fstrace
>> setlog cmfx -buffers 100 ; fstrace sets cm -active ; mkdir whatever
>> & echo $! ; wait ; fstrace dump cm > /tmp/fstrace.log ; fstrace
>> sets cm -inactive) Note that that traces all client activity, so if
>> you've got other AFS-interacting stuff running on the box that you
>> don't want to be public information, don't upload that somewhere
>> public.
>
> Ok, fstrace made with that problem occuring:
> http://tetris.cgv.tugraz.at/afs/fstrace.31.07.2012.txt

the trace shows ENOENT for extern, and later symlink succeeds for extern2
we never see 1702200769 via a GetVolumeByName nor indeed anything.
when did the fstrace run from and to (did your mount point succeed
while it was running?)
what existed before and what commands were run, where?

>> And it doesn't really "solve" the problem, but if you see a client
>> in that state, you may be able to get it out with a 'fs flush .' in
>> the problematic directory (or 'fs flushv' to just flush everyting
>> in the vol). 'fs checks' and 'fs checkv' can also be tried, though
>> it doesn't seem like that would be the problem here.
>
> A fs flush did not help.
> A fs flushv did helped and I can access the new mounted volume.
>
> MfG,
> Lars Schimmer
> - --
> - -------------------------------------------------------------
> TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung
> Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
> Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlAXqlQACgkQmWhuE0qbFyOSngCdF2BYIyl3vdhSU2DMotZAK6OS
> S5YAnjJ8kR1ZMF8ZyMOo3HssNF6gAjUS
> =3DOmV9
> -----END PGP SIGNATURE-----
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info



--=20
Derrick

From l.schimmer@cgv.tugraz.at  Tue Jul 31 14:44:00 2012
From: l.schimmer@cgv.tugraz.at (Lars Schimmer)
Date: Tue, 31 Jul 2012 15:44:00 +0200
Subject: [OpenAFS] Re: Directories not reachable direct after creation
 - linux 1.6.1 - FSTRACE available
In-Reply-To: 
References: <500551CD.1060402@cgv.tugraz.at> <20120726143019.3866d1f0.adeason@sinenomine.net> <5017AA54.9050504@cgv.tugraz.at> 
Message-ID: <5017E120.3000105@cgv.tugraz.at>

Hello

> Ok, fstrace made with that problem occuring:
> http://tetris.cgv.tugraz.at/afs/fstrace.31.07.2012.txt
>=20
>> the trace shows ENOENT for extern, and later symlink succeeds for exte=
rn2
>> we never see 1702200769 via a GetVolumeByName nor indeed anything.
>> when did the fstrace run from and to (did your mount point succeed
>> while it was running?)
>> what existed before and what commands were run, where?

Ok, sorry, yeah, was kinda short. All happened on the 1.6.1 client machin=
e.
I did a "fs mkmount extern user.extern", it failed and was not reachable
with a no such device error.
I did started the fs trace feature, I tried to enter the extern
directory/volume, which told me again "no such device" and I issued a
"fs mkmount extern2 user.extern" which gave a "no such device error"
after a few second, too.
A ls did not show extern neither extern2.
I waited a few seconds and wrote the fs trace to a file.
Afterwards I did fs flush, no better result, fs flushv and both
directory (extern/extern2) were reachable.


MfG,
Lars Schimmer
--=20
-------------------------------------------------------------
TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723

From adeason@sinenomine.net  Tue Jul 31 15:25:48 2012
From: adeason@sinenomine.net (Andrew Deason)
Date: Tue, 31 Jul 2012 10:25:48 -0400
Subject: [OpenAFS] Re: Directories not reachable direct after creation - linux 1.6.1
References: <500551CD.1060402@cgv.tugraz.at>
 <20120726143019.3866d1f0.adeason@sinenomine.net>
 <5017AA54.9050504@cgv.tugraz.at>
 
 <5017E120.3000105@cgv.tugraz.at>
Message-ID: <20120731102548.5281e07d.adeason@sinenomine.net>

On Tue, 31 Jul 2012 15:44:00 +0200
Lars Schimmer  wrote:

> Ok, sorry, yeah, was kinda short. All happened on the 1.6.1 client
> machine.  I did a "fs mkmount extern user.extern", it failed and was
> not reachable with a no such device error.  I did started the fs trace
> feature, I tried to enter the extern directory/volume

It would be more useful if you could start tracing before the first 'fs
mkmount'. If you have no idea when that will happen, you can enable
tracing with minimal impact by just running e.g.:

fstrace clear cm
fstrace setlog cmfx -buffers 1024
fstrace sets cm -active

which will enable tracing, but the tracing data won't go anywhere. So,
you can leave that turned on for a while. Then as soon as the problem
happens, run:

fstrace dump cm > /whatever

which will output the last N entries in the log. Afterwards, you can
turn off tracing completely with

fstrace sets cm -inactive

-- 
Andrew Deason
adeason@sinenomine.net