From pmetcalf@nd.edu Mon Oct 1 15:45:08 2007 From: pmetcalf@nd.edu (Peter Metcalf) Date: Mon, 01 Oct 2007 10:45:08 -0400 Subject: [OpenAFS] rpmbuild Message-ID: <470107F4.4020409@nd.edu> I have over the past several updates to the kernel failed at building a new module for AFS. Using: rpmbuild --rebuild --target=i686 openafs.src.rpm My error I get: error: line 1: Unknown tag: %kmdl openafs Any help with this one? Pete From sxw@inf.ed.ac.uk Mon Oct 1 15:52:24 2007 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 1 Oct 2007 15:52:24 +0100 Subject: [OpenAFS] rpmbuild In-Reply-To: <470107F4.4020409@nd.edu> References: <470107F4.4020409@nd.edu> Message-ID: On 1 Oct 2007, at 15:45, Peter Metcalf wrote: > I have over the past several updates to the kernel failed at > building a new module for AFS. > Using: rpmbuild --rebuild --target=i686 openafs.src.rpm > My error I get: > error: line 1: Unknown tag: %kmdl openafs > Any help with this one? You're using the ATRPMs packages, and not the OpenAFS ones. Trying asking on their mailing lists. (I think you need an additional RPM macro set installed in order to rebuild atrpms packages - I'm not sure how (or if) this is distributed.) S. From tcreedon@easystreet.net Mon Oct 1 16:41:30 2007 From: tcreedon@easystreet.net (ted creedon) Date: Mon, 1 Oct 2007 08:41:30 -0700 Subject: [OpenAFS] enable transarc paths In-Reply-To: References: <46FEB7CE.2010800@easystreet.net> Message-ID: <006701c80441$8a10a0b0$9501010a@teddoris.fam> This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C80406.DDB1C8B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit good _____ From: Derrick Brashear [mailto:shadow@gmail.com] Sent: Sunday, September 30, 2007 10:18 AM To: ted creedon Cc: OpenAFS-Info Subject: Re: [OpenAFS] enable transarc paths On 9/29/07, ted creedon wrote: Looks like if ./configure --enable-transard-paths is set, binaries are placed in both /usr/local/bin and /usr/afs/bin ver 1.5.25 on AMD 64 sure. and? /usr/afs: servers only /usr/local: the whole tree (also, make install is sort of meaningless with transarc paths and you want make dest... in which case, i promise you, nothing goes in /usr/local) ------=_NextPart_000_0068_01C80406.DDB1C8B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

good

 

From: = Derrick Brashear [mailto:shadow@gmail.com]
Sent: Sunday, September = 30, 2007 10:18 AM
To: ted creedon
Cc: OpenAFS-Info
Subject: Re: [OpenAFS] = enable transarc paths

 

 

On 9/29/07, ted creedon <tcreedon@easystreet.net> wrote:

Looks like if ./configure --enable-transard-paths is set, = binaries are
placed in both /usr/local/bin and /usr/afs/bin

ver 1.5.25 on AMD 64


sure. and?

 

/usr/afs: = servers only
/usr/local: the whole tree

(also, make install is sort of meaningless with transarc paths and you = want make dest... in which case, i promise you, nothing goes in = /usr/local)

 

------=_NextPart_000_0068_01C80406.DDB1C8B0-- From jose.calhariz@tagus.ist.utl.pt Mon Oct 1 18:57:19 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Mon, 1 Oct 2007 18:57:19 +0100 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver Message-ID: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have lost a fileserver because of a corruption on the reiserfs v3. Something like 1000 volumes and 100GB of data were lost. The backups were made using amanda with standard tar. =20 My problem is the recovering of the data to the surviving filesystem is taking too much time. Something like 7 hours to recover 7 GB. Will I need 100hours to recover from tar 100GB? What can be the problem? What I can do to speedup the recovery? I am running Debian etch on servers with openafs 1.4.2-6. Now I have only one fileserver with a RAID5 with 7 disks of 700GB using reiserfsck and 3 small fileservers. =20 Jos=E9 Calhariz --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Infeliz o povo que precisa de herois. -- Bertold Brecht=20 --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHATT/Qlvqh9sPbBoRAinXAJ9KnxmNopA7xZY07QFUpJdnq7Ew+wCgmK3S Q0I/3TTksf5+CRW+d01aCRk= =pyOG -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From shadow@gmail.com Mon Oct 1 19:04:49 2007 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 1 Oct 2007 14:04:49 -0400 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> Message-ID: ------=_Part_6649_1399430.1191261889488 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/1/07, Jose Calhariz wrote: > > > Hi, > > I have lost a fileserver because of a corruption on the reiserfs v3. > Something like 1000 volumes and 100GB of data were lost. The backups > were made using amanda with standard tar. Of the raw fileserver partition or of walking /afs? ------=_Part_6649_1399430.1191261889488 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/1/07, Jose Calhariz <jose.calhariz@tagus.ist.utl.pt> wrote:

Hi,

I have lost a fileserver because of a corruption on the reiserfs v3.
Something like 1000 volumes and 100GB of data were lost.  The backups
were made using amanda with standard tar.

Of the raw fileserver partition or of walking /afs?
 

------=_Part_6649_1399430.1191261889488-- From jose.calhariz@tagus.ist.utl.pt Mon Oct 1 19:17:33 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Mon, 1 Oct 2007 19:17:33 +0100 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> Message-ID: <20071001181733.GB22026@copernico.tagus.ist.utl.pt> --XF85m9dhOBO43t/C Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 01, 2007 at 02:04:49PM -0400, Derrick Brashear wrote: > On 10/1/07, Jose Calhariz wrote: > > > > > > Hi, > > > > I have lost a fileserver because of a corruption on the reiserfs v3. > > Something like 1000 volumes and 100GB of data were lost. The backups > > were made using amanda with standard tar. >=20 >=20 > Of the raw fileserver partition or of walking /afs? By walking /afs. --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Infeliz o povo que precisa de herois. -- Bertold Brecht=20 --XF85m9dhOBO43t/C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHATm9Qlvqh9sPbBoRAlxxAKC4LiROjjJxGn3AtTcjriCrm+8ZBACgs6bD lkD1AKkUogsOfn+4W9YP+44= =/nDl -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From rra@stanford.edu Mon Oct 1 19:25:03 2007 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Oct 2007 11:25:03 -0700 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> (Jose Calhariz's message of "Mon, 1 Oct 2007 18:57:19 +0100") References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> Message-ID: <87lkamg0ao.fsf@windlord.stanford.edu> Jose Calhariz writes: > I have lost a fileserver because of a corruption on the reiserfs v3. > Something like 1000 volumes and 100GB of data were lost. The backups > were made using amanda with standard tar. > My problem is the recovering of the data to the surviving filesystem > is taking too much time. Something like 7 hours to recover 7 GB. > Will I need 100hours to recover from tar 100GB? What did you tar up? I can think of a lot of possibilities (the raw namei filesystem, the contents of AFS archived with admin credentials, tarballs of volume dumps), and the answer somewhat depends. If you've archived AFS via tar using admin credentials, I'm not sure there's anything you can do that's faster than creating new volumes and untarring the contents into those volumes. You can do that directly on the relevant file server to reduce your network latency a little. -- Russ Allbery (rra@stanford.edu) From jose.calhariz@tagus.ist.utl.pt Mon Oct 1 19:39:38 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Mon, 1 Oct 2007 19:39:38 +0100 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <87lkamg0ao.fsf@windlord.stanford.edu> References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> Message-ID: <20071001183938.GA23003@copernico.tagus.ist.utl.pt> --wac7ysb48OaltWcw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 01, 2007 at 11:25:03AM -0700, Russ Allbery wrote: > Jose Calhariz writes: >=20 > > I have lost a fileserver because of a corruption on the reiserfs v3. > > Something like 1000 volumes and 100GB of data were lost. The backups > > were made using amanda with standard tar. >=20 > > My problem is the recovering of the data to the surviving filesystem > > is taking too much time. Something like 7 hours to recover 7 GB. > > Will I need 100hours to recover from tar 100GB? >=20 > What did you tar up? I can think of a lot of possibilities (the raw namei > filesystem, the contents of AFS archived with admin credentials, tarballs > of volume dumps), and the answer somewhat depends. I have tarballs with the contents of AFS using admin credentials. >=20 > If you've archived AFS via tar using admin credentials, I'm not sure > there's anything you can do that's faster than creating new volumes and > untarring the contents into those volumes. You can do that directly on > the relevant file server to reduce your network latency a little. >=20 OK Jos=E9 Calhariz --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Infeliz o povo que precisa de herois. -- Bertold Brecht=20 --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHAT7qQlvqh9sPbBoRAgBFAKDHjhx3RSuVB8ljIYgZXAit1wi7RgCeOHsW ol7FZOnm7au35a6Qj1QlRc8= =sxBJ -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From warlord@MIT.EDU Mon Oct 1 20:41:16 2007 From: warlord@MIT.EDU (Derek Atkins) Date: Mon, 01 Oct 2007 15:41:16 -0400 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <20071001183938.GA23003@copernico.tagus.ist.utl.pt> (Jose Calhariz's message of "Mon\, 1 Oct 2007 19\:39\:38 +0100") References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> Message-ID: Jose Calhariz writes: > On Mon, Oct 01, 2007 at 11:25:03AM -0700, Russ Allbery wrote: >> Jose Calhariz writes: >> >> > I have lost a fileserver because of a corruption on the reiserfs v3. >> > Something like 1000 volumes and 100GB of data were lost. The backups >> > were made using amanda with standard tar. >> >> > My problem is the recovering of the data to the surviving filesystem >> > is taking too much time. Something like 7 hours to recover 7 GB. >> > Will I need 100hours to recover from tar 100GB? >> >> What did you tar up? I can think of a lot of possibilities (the raw namei >> filesystem, the contents of AFS archived with admin credentials, tarballs >> of volume dumps), and the answer somewhat depends. > > I have tarballs with the contents of AFS using admin credentials. Note that you'll have to manually repair the acls; tar doesn't save them. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From jason@rampaginggeek.com Mon Oct 1 21:15:04 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Mon, 01 Oct 2007 16:15:04 -0400 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <20071001183938.GA23003@copernico.tagus.ist.utl.pt> References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> Message-ID: <47015548.2080009@rampaginggeek.com> Jose Calhariz wrote: > On Mon, Oct 01, 2007 at 11:25:03AM -0700, Russ Allbery wrote: > >> Jose Calhariz writes: >> >> >>> I have lost a fileserver because of a corruption on the reiserfs v3. >>> Something like 1000 volumes and 100GB of data were lost. The backups >>> were made using amanda with standard tar. >>> >>> My problem is the recovering of the data to the surviving filesystem >>> is taking too much time. Something like 7 hours to recover 7 GB. >>> Will I need 100hours to recover from tar 100GB? >>> >> What did you tar up? I can think of a lot of possibilities (the raw namei >> filesystem, the contents of AFS archived with admin credentials, tarballs >> of volume dumps), and the answer somewhat depends. >> > > I have tarballs with the contents of AFS using admin credentials. > > >> If you've archived AFS via tar using admin credentials, I'm not sure >> there's anything you can do that's faster than creating new volumes and >> untarring the contents into those volumes. You can do that directly on >> the relevant file server to reduce your network latency a little. >> >> > > OK > > If you're not already, I recommend restoring into a local directory, then copying into AFS. That will at least make the tape part go faster and reduce wear and tear on the tapes and drive. Jason From jose.calhariz@tagus.ist.utl.pt Mon Oct 1 22:14:39 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Mon, 1 Oct 2007 22:14:39 +0100 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> Message-ID: <20071001211438.GA27579@copernico.tagus.ist.utl.pt> --AhhlLboLdkugWU4S Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 01, 2007 at 03:41:16PM -0400, Derek Atkins wrote: > Jose Calhariz writes: >=20 > > On Mon, Oct 01, 2007 at 11:25:03AM -0700, Russ Allbery wrote: > >> Jose Calhariz writes: > >>=20 > >> > I have lost a fileserver because of a corruption on the reiserfs v3. > >> > Something like 1000 volumes and 100GB of data were lost. The backups > >> > were made using amanda with standard tar. > >>=20 > >> > My problem is the recovering of the data to the surviving filesystem > >> > is taking too much time. Something like 7 hours to recover 7 GB. > >> > Will I need 100hours to recover from tar 100GB? > >>=20 > >> What did you tar up? I can think of a lot of possibilities (the raw n= amei > >> filesystem, the contents of AFS archived with admin credentials, tarba= lls > >> of volume dumps), and the answer somewhat depends. > > > > I have tarballs with the contents of AFS using admin credentials. >=20 > Note that you'll have to manually repair the acls; tar doesn't save > them. It's on my todo list, to find a command to export and import AFS acls. So it can be collected by tar. >=20 > -derek >=20 Jos=E9 Calhariz --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Infeliz o povo que precisa de herois. -- Bertold Brecht=20 --AhhlLboLdkugWU4S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHAWM+Qlvqh9sPbBoRAoPkAJ9IYCFMFNQTwCpQPeTz1f6r+tn70QCgrIif gkIpK9gWgynmqhrGcb3mI5U= =AM9z -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From sebby@anl.gov Tue Oct 2 00:01:39 2007 From: sebby@anl.gov (Brian Sebby) Date: Mon, 1 Oct 2007 18:01:39 -0500 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <20071001211438.GA27579@copernico.tagus.ist.utl.pt> References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> <20071001211438.GA27579@copernico.tagus.ist.utl.pt> Message-ID: <20071001230139.GA29588@nausicaa.cis.anl.gov> I ended up writing a script to use the commmand 'vos dump' to dump each AFS volume to a local disk partition, then back up that partition with standard backup utilities. The 'vos dump' command creates a file on the local disk that contains the entire volume, including all of the ACLs. Since you can have links in AFS to the same volume multiple times, it's a lot safer to do volume-based backups rather than walking AFS. I could get you a copy of my dump script if you're interested; I'd just have to scrub out all of our site-specific information. Brian On Mon, Oct 01, 2007 at 10:14:39PM +0100, Jose Calhariz wrote: > On Mon, Oct 01, 2007 at 03:41:16PM -0400, Derek Atkins wrote: > > Jose Calhariz writes: > >=20 > > > On Mon, Oct 01, 2007 at 11:25:03AM -0700, Russ Allbery wrote: > > >> Jose Calhariz writes: > > >>=20 > > >> > I have lost a fileserver because of a corruption on the reiserfs= v3. > > >> > Something like 1000 volumes and 100GB of data were lost. The ba= ckups > > >> > were made using amanda with standard tar. > > >>=20 > > >> > My problem is the recovering of the data to the surviving filesy= stem > > >> > is taking too much time. Something like 7 hours to recover 7 GB= . > > >> > Will I need 100hours to recover from tar 100GB? > > >>=20 > > >> What did you tar up? I can think of a lot of possibilities (the r= aw namei > > >> filesystem, the contents of AFS archived with admin credentials, t= arballs > > >> of volume dumps), and the answer somewhat depends. > > > > > > I have tarballs with the contents of AFS using admin credentials. > >=20 > > Note that you'll have to manually repair the acls; tar doesn't save > > them. >=20 > It's on my todo list, to find a command to export and import AFS > acls. So it can be collected by tar. >=20 > >=20 > > -derek > >=20 >=20 > Jos=E9 Calhariz >=20 > --=20 > P.S. [En_US] The sig below is from my random sig-generator, which stran= gely > often seems to pick signatures which are apropriate to the message at > hand! >=20 > P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de > assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas qu= e > parecem apropriadas ao email! > -- > Infeliz o povo que precisa de herois. > -- Bertold Brecht=20 --=20 Brian Sebby (sebby@anl.gov) | Unix and Operation Services Phone: +1 630.252.9935 | Computing and Information Systems Fax: +1 630.252.4601 | Argonne National Laboratory From chas@cmf.nrl.navy.mil Tue Oct 2 00:15:43 2007 From: chas@cmf.nrl.navy.mil (chas williams - CONTRACTOR) Date: Mon, 01 Oct 2007 19:15:43 -0400 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <87lkamg0ao.fsf@windlord.stanford.edu> Message-ID: <200710012315.l91NFhuY019260@cmf.nrl.navy.mil> In message <87lkamg0ao.fsf@windlord.stanford.edu>,Russ Allbery writes: >If you've archived AFS via tar using admin credentials, I'm not sure >there's anything you can do that's faster than creating new volumes and >untarring the contents into those volumes. You can do that directly on >the relevant file server to reduce your network latency a little. i would guess that vos restore restore from a file would be a bit faster than using tar to copy in and out of the cache manager. i dont have any timing to prove this one way or the other though. as for dumping, vol-dump seems pretty speedy but its got a few issues, as i recall: http://www.openafs.org/pipermail/openafs-devel/2004-July/010774.html From l.schimmer@cgv.tugraz.at Tue Oct 2 08:58:13 2007 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Tue, 02 Oct 2007 09:58:13 +0200 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <200710012315.l91NFhuY019260@cmf.nrl.navy.mil> References: <200710012315.l91NFhuY019260@cmf.nrl.navy.mil> Message-ID: <4701FA15.6000400@cgv.tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 chas williams - CONTRACTOR wrote: > In message <87lkamg0ao.fsf@windlord.stanford.edu>,Russ Allbery writes: >> If you've archived AFS via tar using admin credentials, I'm not sure >> there's anything you can do that's faster than creating new volumes an= d >> untarring the contents into those volumes. You can do that directly o= n >> the relevant file server to reduce your network latency a little. >=20 > i would guess that vos restore restore from a file would be a bit faste= r > than using tar to copy in and out of the cache manager. i dont have > any timing to prove this one way or the other though. >=20 > as for dumping, vol-dump seems pretty speedy but its got a few > issues, as i recall: >=20 > http://www.openafs.org/pipermail/openafs-devel/2004-July/010774.html If locking is the problem, create a backup volume of the RW volume and dump the backup volume. This way vos dump doesn't lock the RW volume. Works fine here. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHAfoVmWhuE0qbFyMRAmwMAJ41ulvOZYd43a+I5pGnMIL93X8sgwCeMvQx FS2+z+gBXwHnW16ECj2NipE=3D =3DOOY4 -----END PGP SIGNATURE----- From jose.calhariz@tagus.ist.utl.pt Tue Oct 2 06:00:06 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Tue, 2 Oct 2007 06:00:06 +0100 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <47015548.2080009@rampaginggeek.com> References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> <47015548.2080009@rampaginggeek.com> Message-ID: <20071002050006.GA31045@copernico.tagus.ist.utl.pt> --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 01, 2007 at 04:15:04PM -0400, Jason Edgecombe wrote: > Jose Calhariz wrote: > > On Mon, Oct 01, 2007 at 11:25:03AM -0700, Russ Allbery wrote: > > =20 > >> Jose Calhariz writes: > >> > >> =20 > >>> I have lost a fileserver because of a corruption on the reiserfs v3. > >>> Something like 1000 volumes and 100GB of data were lost. The backups > >>> were made using amanda with standard tar. > >>> =20 > >>> My problem is the recovering of the data to the surviving filesystem > >>> is taking too much time. Something like 7 hours to recover 7 GB. > >>> Will I need 100hours to recover from tar 100GB? > >>> =20 > >> What did you tar up? I can think of a lot of possibilities (the raw n= amei > >> filesystem, the contents of AFS archived with admin credentials, tarba= lls > >> of volume dumps), and the answer somewhat depends. > >> =20 > > > > I have tarballs with the contents of AFS using admin credentials. > > > > =20 > >> If you've archived AFS via tar using admin credentials, I'm not sure > >> there's anything you can do that's faster than creating new volumes and > >> untarring the contents into those volumes. You can do that directly on > >> the relevant file server to reduce your network latency a little. > >> > >> =20 > > > > OK > > > > =20 > If you're not already, I recommend restoring into a local directory, > then copying into AFS. That will at least make the tape part go faster > and reduce wear and tear on the tapes and drive. I am doing that, As I can recover from tapes faster than I can write to AFS. Specially because I use virtual tapes on disks. >=20 > Jason > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >=20 jos=E9 Calhariz --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Infeliz o povo que precisa de herois. -- Bertold Brecht=20 --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHAdBWQlvqh9sPbBoRAv3TAJ4/Tr/Ie5iYKZHlZWFRdyDT5HpHCQCfd7zW qCHIQIel4H5ssMT18307bH0= =m/u6 -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From jason@rampaginggeek.com Tue Oct 2 13:43:07 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Tue, 02 Oct 2007 08:43:07 -0400 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <20071002050006.GA31045@copernico.tagus.ist.utl.pt> References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> <47015548.2080009@rampaginggeek.com> <20071002050006.GA31045@copernico.tagus.ist.utl.pt> Message-ID: <47023CDB.6090104@rampaginggeek.com> Jose Calhariz wrote: >> If you're not already, I recommend restoring into a local directory, >> then copying into AFS. That will at least make the tape part go faster >> and reduce wear and tear on the tapes and drive. >> > > I am doing that, As I can recover from tapes faster than I can write to > AFS. Specially because I use virtual tapes on disks. > Do you have multiple AFS servers? If so, are you copying files to different servers simultaneously? Perhaps it's worthwhile to set up a temporary server and then do a "vos move" of the volumes after everything has settled. Jason From cclausen@acm.org Tue Oct 2 14:23:03 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Tue, 2 Oct 2007 08:23:03 -0500 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> <47015548.2080009@rampaginggeek.com> <20071002050006.GA31045@copernico.tagus.ist.utl.pt> <47023CDB.6090104@rampaginggeek.com> Message-ID: <1B8B9DF35E3F49C39AFCB93D6662FD06@CDCHOME> Jason Edgecombe wrote: > Jose Calhariz wrote: >>> If you're not already, I recommend restoring into a local directory, >>> then copying into AFS. That will at least make the tape part go >>> faster and reduce wear and tear on the tapes and drive. >>> >> >> I am doing that, As I can recover from tapes faster than I can >> write to AFS. Specially because I use virtual tapes on disks. >> > Do you have multiple AFS servers? If so, are you copying files to > different servers simultaneously? Perhaps it's worthwhile to set up a > temporary server and then do a "vos move" of the volumes after > everything has settled. What are the settings on the client you are using to restore the files into AFS? I'd suggest maybe using a memcache while doing restores. Should avoid needing to write the data into the AFS cache file. Additionally, is the AFS cache file on the same block device as your vice partitions? Keeping things on seperate physical disks should help. < (Jose Calhariz's message of "Mon\, 1 Oct 2007 22\:14\:39 +0100") References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> <20071001211438.GA27579@copernico.tagus.ist.utl.pt> Message-ID: Jose Calhariz writes: >> Note that you'll have to manually repair the acls; tar doesn't save >> them. > > It's on my todo list, to find a command to export and import AFS > acls. So it can be collected by tar. I'll also point out that using tar to backup AFS is a bad idea because of potential loops. You're much better off iterating and dumping each volume to a file and then backing up the file. You could even do incremental dumps, too, so you don't need to backup all your data every time. This can save you time AND effort because it'll be much faster to backup AND restore, and it'll save proper volume mountpoints and ACLs automatically for you. Yes, I know it doesn't help you with your current restore process, but it will help you next time. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From tcreedon@easystreet.net Tue Oct 2 15:49:08 2007 From: tcreedon@easystreet.net (ted creedon) Date: Tue, 2 Oct 2007 07:49:08 -0700 Subject: [OpenAFS] OpenAFS, NAT, IPtables In-Reply-To: References: <20070928203955.GI20922@asu.edu> <46FD771E.8050007@rampaginggeek.com> <20070928233912.GK20922@asu.edu> <46FD9FA6.8030006@depauw.edu> <46FDC03B.6080801@rampaginggeek.com> <46FDC684.5090008@depauw.edu> <004d01c802b4$49fdae70$9501010a@teddoris.fam> <46FF1813.80402@depauw.edu> <007f01c80451$faa887b0$9501010a@teddoris.fam> Message-ID: <00e901c80503$646c2970$9501010a@teddoris.fam> Doesn't look like you got the rest of the message: It ran fine dual homed for a few years until Comcast discovered 8 breaks in the 800 ft cable to my office. Its been replaced with cable in conduit and I'm piecing my life back together with a usable internet connection. Even e-mail was affected periodically. The last 2 years have been sheer hell and I'm trying to reverse engineer the way I did it dual homed AFS. Issues are: 1. eth0 and eth1 sometimes switch between LAN and WAN after running Yast - fix is to identify each by MAC address and assign consistently. This switches the Fwbuilder firewall rules on the AFS Linux box. 2. Revisit the firewall rules now that the problem may have been broken packets. The fact that it AFS worked at all is amazing. 3. There isn't an issue with AFS listening on 2 or more IP addresses. The problem is writing scripts for the SuSE implementation of dhcp (there are 2 selectable versions). When there is an address change a script needs to run. It looks like ddclient is in there somewhere. 4. Normally I document all this on my internal wiki but evidently I didn't. 5. I pay $9/mo for 5 "sticky" ip addresses which are fairly stable for 6 months or more. I use dhs.org to dns serve the addresses. 6. Kerberos seems to work fine in this configuration. Later tedc -----Original Message----- From: Zach [mailto:netrek@gmail.com] Sent: Tuesday, October 02, 2007 5:54 AM To: ted creedon Subject: Re: [OpenAFS] OpenAFS, NAT, IPtables Cool thanks Ted. Zach On 10/1/07, ted creedon wrote: > Well, it turn out that openafs is not on dual homed right now. From ecgarris@iupui.edu Tue Oct 2 16:38:59 2007 From: ecgarris@iupui.edu (Eric Chris Garrison) Date: Tue, 02 Oct 2007 11:38:59 -0400 Subject: [OpenAFS] Metrics... Definition of "accesses"? Message-ID: <47026613.9040505@iupui.edu> Hello, My group is trying to come up with some metrics to measure how busy our OpenAFS service is over time. We've been looking at the output of "vos listvol -extended" for ideas. Things it lists: Number of "accesses in the past day (i.e., vnode references)" Raw Read/Write Stats (same network/diff network vs Auth and Total). These numbers don't seem to correlate in any direct way. If I merely do a directory listing for my own volume, the number of accesses goes up by 9 and there are an additional 2 Auth Reads on a Different Network. Does anyone know the exact definition of accesses? One that could be given to upper management types to define user activity on our servers? Does anyone else do reporting of this nature? If so, what do you use as a metric? Thanks for any suggestions, Chris -- Eric Chris Garrison | Principal Mass Storage Specialist ecgarris@iupui.edu | Indiana University - Research Storage W: 317-278-1207 M: 317-250-8649 | Jabber IM: ecgarris@iupui.edu From jose.calhariz@tagus.ist.utl.pt Tue Oct 2 17:13:02 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Tue, 2 Oct 2007 17:13:02 +0100 Subject: [OpenAFS] Howto speedup the restore of a crashed fileserver In-Reply-To: <1B8B9DF35E3F49C39AFCB93D6662FD06@CDCHOME> References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> <47015548.2080009@rampaginggeek.com> <20071002050006.GA31045@copernico.tagus.ist.utl.pt> <47023CDB.6090104@rampaginggeek.com> <1B8B9DF35E3F49C39AFCB93D6662FD06@CDCHOME> Message-ID: <20071002161302.GA31226@copernico.tagus.ist.utl.pt> --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 02, 2007 at 08:23:03AM -0500, Christopher D. Clausen wrote: > Jason Edgecombe wrote: > > Jose Calhariz wrote: > >>> If you're not already, I recommend restoring into a local directory, > >>> then copying into AFS. That will at least make the tape part go > >>> faster and reduce wear and tear on the tapes and drive. > >>> > >> > >> I am doing that, As I can recover from tapes faster than I can > >> write to AFS. Specially because I use virtual tapes on disks. > >> > > Do you have multiple AFS servers? If so, are you copying files to > > different servers simultaneously? Perhaps it's worthwhile to set up a > > temporary server and then do a "vos move" of the volumes after > > everything has settled. >=20 > What are the settings on the client you are using to restore the files=20 > into AFS? I'd suggest maybe using a memcache while doing restores.=20 > Should avoid needing to write the data into the AFS cache file.=20 > Additionally, is the AFS cache file on the same block device as your=20 > vice partitions? Keeping things on seperate physical disks should > help. The /vicep partitions are on RAID5 by hardware, different from the system disks that are two independent disks on RAID1 by software. I have tried memcache, it's faster, tried to setup a disc cache on a tmpfs filesystems, seams to be better. But I don't know to tune a disc cache on tmpfs. To be correct the disc cache is on a file with a ext2 filesystem, that is stored on a tmpfs, with a size of 25% of the RAM on the server. Other very important factor is the load the clients have over the production servers file servers. The speed of recovery on the night is like 10 times faster than on the day. I will setup an extra file server to speed the recovery. >=20 > <=20 Jos=E9 Calhariz --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Nenhum l=EDder, por maior que seja, pode prosseguir por muito tempo, a n=E3= o ser que conquiste vit=F3rias. A batalha decide tudo --Bernard Law Montgomery --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHAm4OQlvqh9sPbBoRAmnuAKCNX+/3qZaCKvFWvCWByYoqqyjJIQCgtKtU VuDJcrAD1YrZ+fX5I574VPY= =Wr20 -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From scs@umich.edu Tue Oct 2 21:01:08 2007 From: scs@umich.edu (Steve Simmons) Date: Tue, 2 Oct 2007 16:01:08 -0400 Subject: [OpenAFS] AES Support ? In-Reply-To: <20830.1190917924@malison.ait.iastate.edu> References: <20830.1190917924@malison.ait.iastate.edu> Message-ID: On Sep 27, 2007, at 2:32 PM, John Hascall wrote: >> The same is true of disabling DES >> keys in >> your Kerberos v5 realm (have you done that yet?). > > Surely you jest, we're still struggling to get rid of K4. Actually, our k4 to k5 conversion turned out to be a reasonable (if exhausting) model of how to do it - Start monitoring k4 use and twisting arms. Escalated threats^H^H^H^H^H^H^H efforts accompanied by examples from other universities getting hacked ("You don't want to wind up like Ohio State" is a very potent phrase at Michigan). Rolling cycles of: 1. Pick a subnet 2. Identify k4 users/hosts 3. Announce to them a date that k4 will stop working, repeatedly in their face. "Yes, we mean you." 4. Filter out k4 traffic on date. 5. If no problems, done. Otherwise loosen up filter a bit and return to step 3 for ever-smaller set of users. You can do many subnets simultaneously. I think it took us nearly a year, but my brain refuses to disgorge the details. And we still have a few legacy administrative hosts doing k4, but it's completely blocked for everything except those few IP addresses. And those machines are in process of being de-commed. Which reminds me, I need to go power down one of them. The same process has to be applied with DES. From jose.calhariz@tagus.ist.utl.pt Tue Oct 2 20:55:50 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Tue, 2 Oct 2007 20:55:50 +0100 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 Message-ID: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This mailing list knows that in Debian etch where stack is limited by default to 8192, may not be enough to run a fileserver? I know the Debian Packagers of openafs read this list. Should I send a bug report to Debian or is this a known bug and fixed on a newer package? I didn't find anything about this in Debian Bug Tracking System. I have hacked a solution, but other people may be bitten by this problem. By default ulimit -a is: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice (-e) 0 file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited max rt priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Jos=E9 Calhariz --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Fazer dinheiro =E9 arte, trabalhar =E9 arte e bons neg=F3cios s=E3o a melho= r arte de todas --Andy Warhol --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHAqJGQlvqh9sPbBoRAgTpAJ9aQV8ps0mh7ZT6f7/kBy7Kox5/1gCfXrR0 t18B3QLb7ap5VW2iQ+KAAy0= =F+KT -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From rra@stanford.edu Wed Oct 3 06:58:20 2007 From: rra@stanford.edu (Russ Allbery) Date: Tue, 02 Oct 2007 22:58:20 -0700 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> (Jose Calhariz's message of "Tue, 2 Oct 2007 20:55:50 +0100") References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> Message-ID: <87y7ek91tv.fsf@windlord.stanford.edu> Jose Calhariz writes: > This mailing list knows that in Debian etch where stack is limited by > default to 8192, may not be enough to run a fileserver? I'm running ten production AFS file servers for Stanford University on Debian etch and have never had a problem with this. Under what circumstances did you run into trouble? -- Russ Allbery (rra@stanford.edu) From jose.calhariz@tagus.ist.utl.pt Wed Oct 3 11:31:59 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Wed, 3 Oct 2007 11:31:59 +0100 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <87y7ek91tv.fsf@windlord.stanford.edu> References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> <87y7ek91tv.fsf@windlord.stanford.edu> Message-ID: <20071003103159.GA13953@copernico.tagus.ist.utl.pt> --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 02, 2007 at 10:58:20PM -0700, Russ Allbery wrote: > Jose Calhariz writes: >=20 > > This mailing list knows that in Debian etch where stack is limited by > > default to 8192, may not be enough to run a fileserver? >=20 > I'm running ten production AFS file servers for Stanford University on > Debian etch and have never had a problem with this. Under what > circumstances did you run into trouble? >=20 I have only 2 fileservers foo and bar :-)=20 When server bar started with problems I initiated to move online the volumes from server bar to server foo. Before the finish of the move I had to stop server bar to do a fsck on /vicepa that failed. While I was trying to make fsck succeed on bar, foo does the programed restart on 4 am of Sunday. On the morning of Sunday I found the two fileservers down, my extra 3 DB/Mail servers with problems because the mail server had started to many process, and last but not least my backup server couldn't start=20 because of the afs client. It was stopping on the launch of afsd. On foo server I didn't find any good message error message on /var/log/openafs behind the Salvage that finished with success. Whenever I had done /etc/init.d/openafs-fileserver stop and start the foo server went into Salvage and in the end I couldn't get a "vos listvol foo". Restarting the 3 extra DB/Mail servers solved problems with the backup server. After this I tried a hint I found in the Internet, someone with the same problem like I had with foo server, said ulimit -s 8192 was not enough and would bug report to Debian. So I have done an "ulimit -s unlimited" on shell and started one more time the fileserver. This time after a successful salvage I had the volumes online.=20 I didn't found any bug report on BTS or on the changelog about this issue. So I am asking here. As more people could had this same issue on other Linux distributions or Unix. Maybe my problem was the 3 extra DB server with problems, as I didn't had enough DB servers for quorum, I had maybe 1 or 2 DB servers out of 5. =20 Jos=E9 Calhariz --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Onde quer que voc=EA esteja, voc=EA sempre estar=E1 l=E1! --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHA2+fQlvqh9sPbBoRAobcAJ9NHXDefsa/FzwVGWhq89MC0QYoFQCgoGVo 9jg5cKuWTn5nzI0xZfhxOrY= =57NL -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From rra@stanford.edu Wed Oct 3 18:58:07 2007 From: rra@stanford.edu (Russ Allbery) Date: Wed, 03 Oct 2007 10:58:07 -0700 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <20071003103159.GA13953@copernico.tagus.ist.utl.pt> (Jose Calhariz's message of "Wed, 3 Oct 2007 11:31:59 +0100") References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> <87y7ek91tv.fsf@windlord.stanford.edu> <20071003103159.GA13953@copernico.tagus.ist.utl.pt> Message-ID: <87y7ekullc.fsf@windlord.stanford.edu> Jose Calhariz writes: > When server bar started with problems I initiated to move online the > volumes from server bar to server foo. Before the finish of the move I > had to stop server bar to do a fsck on /vicepa that failed. Why did you have to stop the server? Why did you have to do an fsck? > On the morning of Sunday I found the two fileservers down, my extra 3 > DB/Mail servers with problems because the mail server had started to > many process, and last but not least my backup server couldn't start > because of the afs client. It was stopping on the launch of afsd. You probably want to be using -dynroot on your AFS clients, although if your VLDB servers were down, that may not be enough; I don't remember. Anyway, that would just let afsd start; it wouldn't help with not being able to see your cell. > On foo server I didn't find any good message error message on > /var/log/openafs behind the Salvage that finished with success. The information about why the file server died should be in the last lines of FileLog.old unless it died with a signal, such as a segfault. If it did the latter, that information will be in the BosLog. What does BosLog say? Do you have a core file? If it died with a signal (like BUS or SEGV), you should have a core file; check /var/log/openafs. If you don't have a core file, investigate whether you accidentally started the file server with core dumps disabled. > Whenever I had done /etc/init.d/openafs-fileserver stop and start the > foo server went into Salvage and in the end I couldn't get a "vos > listvol foo". Why couldn't you? What error message did you get? What did the salvage log say? What did the FileLog say after salvaging finished? > Restarting the 3 extra DB/Mail servers solved problems with the backup > server. If your VLDB servers were all down, that may be why your file server couldn't start. > After this I tried a hint I found in the Internet, someone with the same > problem like I had with foo server, said ulimit -s 8192 was not enough > and would bug report to Debian. So I have done an "ulimit -s unlimited" > on shell and started one more time the fileserver. This time after a > successful salvage I had the volumes online. You sure that wasn't because you fixed your VLDB server? > I didn't found any bug report on BTS or on the changelog about this > issue. So I am asking here. As more people could had this same issue > on other Linux distributions or Unix. > Maybe my problem was the 3 extra DB server with problems, as I didn't > had enough DB servers for quorum, I had maybe 1 or 2 DB servers out of > 5. This seems more likely. At least so far, I'm not seeing much indication that the stack size limitation was related to your problem or its resolution, and as mentioned, we're running ten servers with around 15,000 AFS clients on Debian etch without needing to change any process limits from the defaults. -- Russ Allbery (rra@stanford.edu) From jasher1@tampabay.rr.com Wed Oct 3 22:52:31 2007 From: jasher1@tampabay.rr.com (Jesse W. Asher) Date: Wed, 03 Oct 2007 17:52:31 -0400 Subject: [OpenAFS] Commercial support for AFS. Message-ID: <47040F1F.6050809@tampabay.rr.com> I was evaluating AFS for an implementation a few months back and I ran across a couple of companies that provided support for OpenAFS. Unfortunately, I can't remember who they were. I realize that OpenAFS is open source and, personally, I'm sure net-based resources would be sufficient, but this company is voicing a concern about not having a company to fall back on for support. Can anyone recommend some companies that provide full support for OpenAFS? The requirements should be: 1) Can be called 7/24 for support. 2) Able to help diagnose and resolve administrative and configuration issues. 3) Able to diagnose and resolve code type issues (by creating and issuing patches). 4) Be a viable company rather than just a fly by night entity. Any ideas out there? Thanks!! From jaltman@secure-endpoints.com Wed Oct 3 23:05:37 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 03 Oct 2007 18:05:37 -0400 Subject: [OpenAFS] Commercial support for AFS. In-Reply-To: <47040F1F.6050809@tampabay.rr.com> References: <47040F1F.6050809@tampabay.rr.com> Message-ID: <47041231.6090508@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms010909030104070704020606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jesse W. Asher wrote: > > I was evaluating AFS for an implementation a few months back and I ran > across a couple of companies that provided support for OpenAFS. > Unfortunately, I can't remember who they were. I realize that OpenAFS > is open source and, personally, I'm sure net-based resources would be > sufficient, but this company is voicing a concern about not having a > company to fall back on for support. > > Can anyone recommend some companies that provide full support for > OpenAFS? The requirements should be: > > 1) Can be called 7/24 for support. > 2) Able to help diagnose and resolve administrative and configuration > issues. > 3) Able to diagnose and resolve code type issues (by creating and > issuing patches). > 4) Be a viable company rather than just a fly by night entity. > > Any ideas out there? Thanks!! Secure Endpoints Inc. provides support but does not provide 24/7 coverage. http://www.secure-endpoints.com/support/openafs.html Our partner company, Sine Nomine Associates, will provide you 24/7 support. You can contract for SNA support through Secure Endpoints or contact them directly. Jeffrey Altman Secure Endpoints Inc. --------------ms010909030104070704020606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMDMyMjA1MzdaMCMGCSqGSIb3DQEJBDEWBBS3exNT SmzkhrX4+rnK33wb/ncNuDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEANYoPb56KgmsUhjyVewk59/E61p3jk0j0tgEKOsiX1SSoEPRwV3gy LFOmME8XqOaPY9cYspAh8ckcssYHBJ9/g1yb6Dc+FULx4J9agsOJ+FUK8QKGrdnx5bx20Ih8 siFE6XyekSV8x/BHhOwDH3ZYbqjVbs9WWAgdpWpoV0rgf4pBTNnQEV0sT2JiTfz5CrAVdkEV /pUa05/l9GOVwn0Rt2V7X3UJvdvL1j22aB9AUzUj6Krr2AbOISXZSOUlltuzavFbUisCJtGo Va3fAtfX/rBXe8wFS3WiYPgQ+I/+rEB1wzdbAVE3LaxK9CfNh2cVh87f3Iu1LzZCCoPbpqZU FAAAAAAAAA== --------------ms010909030104070704020606-- From steven.jenkins@gmail.com Wed Oct 3 23:58:58 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 3 Oct 2007 18:58:58 -0400 Subject: [OpenAFS] Commercial support for AFS. In-Reply-To: <47040F1F.6050809@tampabay.rr.com> References: <47040F1F.6050809@tampabay.rr.com> Message-ID: On 10/3/07, Jesse W. Asher wrote: > > I was evaluating AFS for an implementation a few months back and I ran > across a couple of companies that provided support for OpenAFS. > Unfortunately, I can't remember who they were. I realize that OpenAFS > is open source and, personally, I'm sure net-based resources would be > sufficient, but this company is voicing a concern about not having a > company to fall back on for support. > > Can anyone recommend some companies that provide full support for > OpenAFS? The requirements should be: > > 1) Can be called 7/24 for support. > 2) Able to help diagnose and resolve administrative and configuration > issues. > 3) Able to diagnose and resolve code type issues (by creating and > issuing patches). > 4) Be a viable company rather than just a fly by night entity. > > Any ideas out there? Thanks!! > The place you saw some companies listed may be the AFS Lore wiki: http://www.dementia.org/twiki/bin/view/AFSLore/WhereToGetHelp Steven From sebby@anl.gov Thu Oct 4 00:47:52 2007 From: sebby@anl.gov (Brian Sebby) Date: Wed, 3 Oct 2007 18:47:52 -0500 Subject: [OpenAFS] [REVIEW] Can haz Solaris 10 8/07 compatibility patch In-Reply-To: References: Message-ID: <20071003234752.GA14129@nausicaa.cis.anl.gov> I wanted to note that we have discovered that Sun has now released patches that will cause the same problems introduced in update 4 to occur in pre-u4 systems. Specifically, the installation of the following patches. Sparc: 120011-14: SunOS 5.10: kernel patch Prerequisites: 125547-02: SunOS 5.10: zoneadm indirect dependency patch 122660-10: SunOS 5.10: zones patch x86: 120012-14: SunOS 5.10_x86: kernel patch I don't know what the prerequisites are for x86; we're a Sparc-only shop. I just wanted to send out a warning in case anyone hasn't updated their u3 and earlier Solaris 10 systems. Once we installed the module with Dale's patch, the systems worked fine. Brian On Wed, Sep 26, 2007 at 07:35:44PM -0400, Dale Ghent wrote: > > Here's a candidate patch for those of you running any version of > Solaris 10, or have hopes of running OpenAFS on Solaris 10 8/07 > (update 4); > > This patch removes use of the non-Public ILL structures by OpenAFS to > gather network interface information in order to make RX packet size > and server locality decisions. I replaced it with a Solaris taskq(9f) > that executes a function which polls the network interfaces on the > machine and populates a global array with collected information. > Network information consumers then walk this array to gain the info > they require. This polling function, by default, runs every 30 seconds. > > I made a design change from previous versions in that I dispensed > with the while(1) loop for the polling mechanism. The osi_NetIfPoller > function now chains itself. > > The interval between polls may be adjusted either by /etc/system or > in real time by the use of mdb: > > Set afs interface poll interval to 15 seconds using /etc/system: > set afs:afs_if_poll_interval=15 > > Get current poll interval using mdb: > # echo afs_if_poll_interval/D | mdb -k > afs_if_poll_interval: > afs_if_poll_interval: 30 > > Set a new poll interval to 15 seconds (in hex): > # echo "afs_if_poll_interval/W 0f" | mdb -kw > afs_if_poll_interval: 0x1e = 0xf > > You may see if the poller is doing its job by watching the "executed" > line of the afs_taskq kstat: > # kstat -n afs_taskq > module: unix instance: 0 > name: afs_taskq class: taskq > crtime 141.142208577 > executed 126 > maxtasks 1 > nactive 2 > nalloc 0 > priority 60 > snaptime 2286.25972396 > tasks 126 > threads 2 > totaltime 28790720 > > The following patch applies against OpenAFS 1.4.4. I urge that it be > tested on any version of Solaris that you may have at your disposal, > not just 10u4. Please discuss any issues on the -devel list. > > http://elektronkind.org/outbox/afs/openafs-s10u4-compat.patch > > /dale > -- > Dale Ghent > Specialist, Storage and UNIX Systems > UMBC - Office of Information Technology > ECS 201 - x51705 > > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Brian Sebby (sebby@anl.gov) | Unix and Operation Services Phone: +1 630.252.9935 | Computing and Information Systems Fax: +1 630.252.4601 | Argonne National Laboratory From jose.calhariz@tagus.ist.utl.pt Thu Oct 4 01:11:22 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Thu, 4 Oct 2007 01:11:22 +0100 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <87y7ekullc.fsf@windlord.stanford.edu> References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> <87y7ek91tv.fsf@windlord.stanford.edu> <20071003103159.GA13953@copernico.tagus.ist.utl.pt> <87y7ekullc.fsf@windlord.stanford.edu> Message-ID: <20071004001122.GA5320@copernico.tagus.ist.utl.pt> --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 03, 2007 at 10:58:07AM -0700, Russ Allbery wrote: > Jose Calhariz writes: >=20 > > When server bar started with problems I initiated to move online the > > volumes from server bar to server foo. Before the finish of the move I > > had to stop server bar to do a fsck on /vicepa that failed. >=20 > Why did you have to stop the server? Why did you have to do an > fsck? I had an error message from the reiserfs, on Thursday night. But the corruption went bigger, and more and more volumes were going offline. So I stop it to do an fsck. That't when the fsck failed. I didn't stopped the fileserver on Friday because was production hours. Maybe my killing mistake. =20 Just to be clear you are here asking about the bar server. The one I lost the /vicepa partition. It is the foo server that didn't restart, maybe because ulimit -s 8192. >=20 > > On the morning of Sunday I found the two fileservers down, my extra 3 > > DB/Mail servers with problems because the mail server had started to > > many process, and last but not least my backup server couldn't start > > because of the afs client. It was stopping on the launch of afsd. >=20 > You probably want to be using -dynroot on your AFS clients, although if > your VLDB servers were down, that may not be enough; I don't remember. > Anyway, that would just let afsd start; it wouldn't help with not being > able to see your cell. Some clients didn't had problems. I checked other similar client and it worked. My VLDB servers are file servers for root.cell and root.afs. Maybe the clients were contacting different RO replicas of root.cell and root.afs. One of them were still good, the other was unresponsive. I can be wrong, but I need to use my root.afs. I need a link on /afs as a shortcut for my cellname. So I can't use -dynroot on some clients. Correct me if I am wrong. >=20 > > On foo server I didn't find any good message error message on > > /var/log/openafs behind the Salvage that finished with success. >=20 > The information about why the file server died should be in the last lines > of FileLog.old unless it died with a signal, such as a segfault. If it > did the latter, that information will be in the BosLog. What does BosLog > say? Do you have a core file? If it died with a signal (like BUS or > SEGV), you should have a core file; check /var/log/openafs. If you don't > have a core file, investigate whether you accidentally started the file > server with core dumps disabled. I am talking by memory, as I didn't saved the log files. I had seen messages of exit with various numbers, 0, 1 and maybe 15. No core file, how do I enable core files? >=20 > > Whenever I had done /etc/init.d/openafs-fileserver stop and start the > > foo server went into Salvage and in the end I couldn't get a "vos > > listvol foo". >=20 > Why couldn't you? What error message did you get? What did the salvage > log say? What did the FileLog say after salvaging finished? >=20 vos listvol returned a communication error, I think the normal when the fileserver is down. The salvage was what I expect of an unclean shutdown of the machine. On logs files I only remember of process exit number. But I don't remember of the exit number or the exact program. It could be the VL program crashing instead of the filserver. I am going to do a restart of the fileserver to check if this condition really still exist. > > Restarting the 3 extra DB/Mail servers solved problems with the backup > > server. >=20 > If your VLDB servers were all down, that may be why your file server > couldn't start. I believe the VLDB start to have problems after my foo server went down, that server brougth down all the remaing Maildirs to deposit mail. So the mailservers running on the last 3 VLDB machines, caused a DoS on the machines. The other 2 VLDB servers were on the stopped fileservers.=20 >=20 > > After this I tried a hint I found in the Internet, someone with the same > > problem like I had with foo server, said ulimit -s 8192 was not enough > > and would bug report to Debian. So I have done an "ulimit -s unlimited" > > on shell and started one more time the fileserver. This time after a > > successful salvage I had the volumes online. >=20 > You sure that wasn't because you fixed your VLDB server? I want to test it again. I couldn't do a proper debug of the situation. Too many problems at the same time and too litle hours of sleep :-( >=20 > > I didn't found any bug report on BTS or on the changelog about this > > issue. So I am asking here. As more people could had this same issue > > on other Linux distributions or Unix. >=20 > > Maybe my problem was the 3 extra DB server with problems, as I didn't > > had enough DB servers for quorum, I had maybe 1 or 2 DB servers out of > > 5. >=20 > This seems more likely. At least so far, I'm not seeing much indication > that the stack size limitation was related to your problem or its > resolution, and as mentioned, we're running ten servers with around 15,000 > AFS clients on Debian etch without needing to change any process limits > from the defaults. >=20 I to have another cell with more volumes per fileserver, whithout problems. =20 I am going todo a restart of the foo server. What I need to check if it fails, besides the logs files on /var/log/openafs and the existence of the core file. --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- Um homem n=E3o =E9 necessariamente inteligente porque tem boas id=E9ias, da= mesma forma que n=E3o =E9 bom general por ter muitos soldados --Nicolas Chamfort --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHBC+qQlvqh9sPbBoRApC4AKC/EpD6+sGlnecZLvBBpZ/mvsgWLgCeIBFP 6wUthkreLE8ovRz31PfgVi0= =sBMv -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From zeroguy@verizon.net Thu Oct 4 01:42:26 2007 From: zeroguy@verizon.net (Andrew Deason) Date: Wed, 3 Oct 2007 19:42:26 -0500 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <20071004001122.GA5320@copernico.tagus.ist.utl.pt> References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> <87y7ek91tv.fsf@windlord.stanford.edu> <20071003103159.GA13953@copernico.tagus.ist.utl.pt> <87y7ekullc.fsf@windlord.stanford.edu> <20071004001122.GA5320@copernico.tagus.ist.utl.pt> Message-ID: <20071003194226.5785070f.zeroguy@verizon.net> On Thu, 04 Oct 2007 01:11:22 +0100 Jose Calhariz wrote: > I can be wrong, but I need to use my root.afs. I need a link on /afs > as a shortcut for my cellname. So I can't use -dynroot on some > clients. Correct me if I am wrong. You can use -dynroot and still achieve this by using a CellAlias file. If you put "my.cell.name my" in /etc/openafs/CellAlias (or /usr/vice/etc/CellAlias if using transarc paths), -dynroot will provide a symlink my->my.cell.name in /afs. -- Andrew Deason zeroguy@verizon.net From rra@stanford.edu Thu Oct 4 01:43:06 2007 From: rra@stanford.edu (Russ Allbery) Date: Wed, 03 Oct 2007 17:43:06 -0700 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <20071004001122.GA5320@copernico.tagus.ist.utl.pt> (Jose Calhariz's message of "Thu, 4 Oct 2007 01:11:22 +0100") References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> <87y7ek91tv.fsf@windlord.stanford.edu> <20071003103159.GA13953@copernico.tagus.ist.utl.pt> <87y7ekullc.fsf@windlord.stanford.edu> <20071004001122.GA5320@copernico.tagus.ist.utl.pt> Message-ID: <87bqbfvhet.fsf@windlord.stanford.edu> Jose Calhariz writes: > I had an error message from the reiserfs, on Thursday night. But the > corruption went bigger, and more and more volumes were going offline. > So I stop it to do an fsck. That't when the fsck failed. I didn't > stopped the fileserver on Friday because was production hours. Maybe my > killing mistake. Ah, okay. I definitely recommend against using ReiserFS for any production purposes (completely apart from whether you use AFS or not). > I can be wrong, but I need to use my root.afs. I need a link on /afs as > a shortcut for my cellname. So I can't use -dynroot on some clients. > Correct me if I am wrong. This is what the CellAlias configuration file is for. It's hard to tell exactly why the client didn't work; it doesn't sound like you have much information about what failed or what could have been happening. > I am talking by memory, as I didn't saved the log files. I had seen > messages of exit with various numbers, 0, 1 and maybe 15. No core file, > how do I enable core files? Make sure that you don't have core limit size limited when you start the file server and they should happen automatically if the file server actually fails. But if you don't have any exit status other than 0, 1, and 15, the file server isn't failing. Which again raises the question of what the problem actually is. If the file server is not existing with any status other than those three, I'm 99% certain that the stack limit is not an issue for you. What I would expect, were it to run into a stack limit, would be a bus error or segfault. > vos listvol returned a communication error, I think the normal when > the fileserver is down. When the volserver is down, yes. But once the salvage is finished, it should be started. > I want to test it again. I couldn't do a proper debug of the situation. > Too many problems at the same time and too litle hours of sleep :-( Yeah, I understand there. It's hard in those situations to know what debugging information to get. > I am going todo a restart of the foo server. What I need to check if it > fails, besides the logs files on /var/log/openafs and the existence of > the core file. If you have all the log files and can put them somewhere where others can look at them, that would be very helpful. Be more cautious about the core file, since it will contain your cell key. But it sounds like the file server may not be failing. The log files will probably be the most useful here. -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Thu Oct 4 03:21:20 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 03 Oct 2007 22:21:20 -0400 Subject: [OpenAFS] OpenAFS for Windows vs German Vista Message-ID: <47044E20.20204@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms070003080701080401000007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If you have successfully or unsuccessfully installed OpenAFS for Windows 1.5.25 on German Windows. Please let me know. Jeffrey Altman --------------ms070003080701080401000007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMDQwMjIxMjBaMCMGCSqGSIb3DQEJBDEWBBT5EHP9 qDGjLwHU7QL3AtaF/VRVXTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAY8Py9yyBq4p5M1jVCgxVD9YqvVTsftTKKsNrNPxezt8GHqD4JEIf ZYQ3tehvXd11AAxRgqDVfmq7uD0OdDesP0PA+W4ngvcwZHQfFm6ZHim8q95wfOL7xP+rM0Rn 17geSLJso+egVbWmf5Qp97UnRwkLwyHaN8SNqAYpM1drUAWbsAAoPWGCucReY/AD2F9JzURt R/bUtu8pDZq0WNCvi1kg2FaF9fysA3kTbg36KROWLgxqjM9yCJtz1W+sGLCRBb6w7AWl+Wsr Agy3D8VU60yDwNzzknSYAaf2DrTadoGVMsB2xOhkOEyW+fTLU/Hvgkb/S6C4ujLB2Kywv/31 UQAAAAAAAA== --------------ms070003080701080401000007-- From jose.calhariz@tagus.ist.utl.pt Thu Oct 4 03:19:42 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Thu, 4 Oct 2007 03:19:42 +0100 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <87bqbfvhet.fsf@windlord.stanford.edu> References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> <87y7ek91tv.fsf@windlord.stanford.edu> <20071003103159.GA13953@copernico.tagus.ist.utl.pt> <87y7ekullc.fsf@windlord.stanford.edu> <20071004001122.GA5320@copernico.tagus.ist.utl.pt> <87bqbfvhet.fsf@windlord.stanford.edu> Message-ID: <20071004021942.GA29067@copernico.tagus.ist.utl.pt> --jI8keyz6grp/JLjh Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 03, 2007 at 05:43:06PM -0700, Russ Allbery wrote: > Jose Calhariz writes: >=20 > > I had an error message from the reiserfs, on Thursday night. But the > > corruption went bigger, and more and more volumes were going offline. > > So I stop it to do an fsck. That't when the fsck failed. I didn't > > stopped the fileserver on Friday because was production hours. Maybe my > > killing mistake. >=20 > Ah, okay. >=20 > I definitely recommend against using ReiserFS for any production purposes > (completely apart from whether you use AFS or not). I don't know what happen. I have only two leads. One IO error message from reiserfs on the begin of everything. And after the loss I found a strange behavior with the hardware RAID5. I need to do further investigation. And most important I learned I don't know enough about reiserfs guts. So I really don't understand the error messages from reiserfsck. I will move into ext3, that I know very well, or XFS, I have a local expert that can to help in case o trouble with XFS. I remember see an online presentation from an AFS workshop were XFS was considered best than ext3 for /vicep partitions. >=20 > > I can be wrong, but I need to use my root.afs. I need a link on /afs as > > a shortcut for my cellname. So I can't use -dynroot on some clients. > > Correct me if I am wrong. >=20 > This is what the CellAlias configuration file is for. It's hard to tell > exactly why the client didn't work; it doesn't sound like you have much > information about what failed or what could have been happening. Thank you. I didn't know about that file. >=20 > > I am talking by memory, as I didn't saved the log files. I had seen > > messages of exit with various numbers, 0, 1 and maybe 15. No core file, > > how do I enable core files? >=20 > Make sure that you don't have core limit size limited when you start the > file server and they should happen automatically if the file server > actually fails. =20 Ok, I have by default "ulimit -c 0". I don't depend on core files for so many years I forget about ulimit -c 0. Now I am a sysadm not a programmer. I only program in bash and install gdb for other people to use, not for myself :-) > But if you don't have any exit status other than 0, 1, > and 15, the file server isn't failing. Which again raises the question of > what the problem actually is. >=20 > If the file server is not existing with any status other than those three, > I'm 99% certain that the stack limit is not an issue for you. What I > would expect, were it to run into a stack limit, would be a bus error or > segfault. I have restarted my fileserver. No problem this time with "ulimit -s 8192". So I think you are right. My last 3 VLDB servers were in trouble on that day and were creating more problems everywhere. The salvage was taking 40 minutes, so I had time to solve the other problems before I put all my efforts on the last one. The failing file server.=20 Thank you for your help on this issue. --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- A vantagem de ser milion=E1rio =E9 poder falar o que ser quer, para quem se= quer e como se quer --Pr=EDncipe Johannes von Thurn und --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHBE2+Qlvqh9sPbBoRAmjWAJwKyfk80Wt1O0aPUySGTkbCMHb/AQCgxbsw 1+jl5d6AsYMfswMPoPNIpWk= =UEIK -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From karl@ridgetop-group.com Thu Oct 4 03:40:21 2007 From: karl@ridgetop-group.com (Karl M. Davis) Date: Wed, 3 Oct 2007 19:40:21 -0700 Subject: [OpenAFS] AFS Fileserver Won't Start Message-ID: <008001c8062f$e8fb44f0$baf1ced0$@com> This is a multipart message in MIME format. ------=_NextPart_000_0081_01C805F5.3C9C6CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello all, I'm having a pretty crappy day right now, hope someone can help me out. What started this is my attempt to move our OpenAFS server from a VM to a dedicated physical box. I'm running Ubuntu/Debian and using their openafs packages on both machines. Somewhere towards the end of moving the volumes from the old server to the new server, things got badly goofed. The fs process will no longer start on the new server and I find the following entry in the /var/log/openafs/FileLog file: << Wed Oct 3 19:26:59 2007 File server starting Wed Oct 3 19:26:59 2007 afs_krb_get_lrealm failed, using ridgetop-group.local. Wed Oct 3 19:26:59 2007 VL_RegisterAddrs rpc failed; The IP address exists on a different server; repair it Wed Oct 3 19:26:59 2007 VL_RegisterAddrs rpc failed; See VLLog for details Wed Oct 3 19:26:59 2007 Fatal error in library initialization, exiting!! >> Unfortunately, there's nothing helpful in VLLog. Interestingly, "vos listaddrs" returns nothing on the new server, either. Running "vos listvldb" returns the following: << VLDB entries for all servers lib RWrite: 536870933 number of sites -> 1 server picacho.ridgetop-group.local partition /vicepa RW Site lib.pdks RWrite: 536870936 number of sites -> 1 server picacho.ridgetop-group.local partition /vicepa RW Site root.afs RWrite: 536870915 ROnly: 536870916 number of sites -> 3 server picacho.ridgetop-group.local partition /vicepa RW Site server picacho.ridgetop-group.local partition /vicepa RO Site server picacho.ridgetop-group.local partition /vicepa RO Site root.cell RWrite: 536870918 ROnly: 536870919 number of sites -> 3 server picacho.ridgetop-group.local partition /vicepa RW Site server picacho.ridgetop-group.local partition /vicepa RO Site server picacho.ridgetop-group.local partition /vicepa RO Site Total entries: 4 >> I'm unsure why there are duplicate RO entries, but the last thing I was working on was recreating RO volumes for root.cell and root.afs on the new server. I'm panicking because all of the volumes are now on the new server and non-accessible. Anyone have some clue what I did wrong and how I can fix things? Thanks! Karl ------=_NextPart_000_0081_01C805F5.3C9C6CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I’m having a pretty crappy day right now, = hope someone can help me out.

 

What started this is my attempt to move our OpenAFS = server from a VM to a dedicated physical box.  I’m running = Ubuntu/Debian and using their openafs packages on both machines.

 

Somewhere towards the end of moving the volumes = from the old server to the new server, things got badly goofed.  The fs process = will no longer start on the new server and I find the following entry in the /var/log/openafs/FileLog file:

<< 

Wed = Oct  3 19:26:59 2007 File server starting

Wed = Oct  3 19:26:59 2007 afs_krb_get_lrealm failed, using = ridgetop-group.local.

Wed = Oct  3 19:26:59 2007 VL_RegisterAddrs rpc failed; The IP address exists on a = different server; repair it

Wed = Oct  3 19:26:59 2007 VL_RegisterAddrs rpc failed; See VLLog for = details

Wed = Oct  3 19:26:59 2007 Fatal error in library initialization, = exiting!!

>> 

 

Unfortunately, there’s nothing helpful in = VLLog.  Interestingly, “vos listaddrs” returns nothing on the new = server, either.

 

Running “vos listvldb” returns the = following:

<< 

VLDB = entries for all servers

 

lib

    RWrite: 536870933

    number of sites -> 1

       server picacho.ridgetop-group.local partition /vicepa RW = Site

 

lib.pdks

    RWrite: 536870936

    number of sites -> 1

       server picacho.ridgetop-group.local partition /vicepa RW = Site

 

root.afs

    RWrite: 536870915     ROnly: = 536870916

    number of sites -> 3

       server picacho.ridgetop-group.local partition /vicepa RW = Site

       server picacho.ridgetop-group.local partition /vicepa RO = Site

       server picacho.ridgetop-group.local partition /vicepa RO = Site

 

root.cell

    RWrite: 536870918     ROnly: = 536870919

    number of sites -> 3

       server picacho.ridgetop-group.local partition /vicepa RW = Site

       server picacho.ridgetop-group.local partition /vicepa RO = Site

       server picacho.ridgetop-group.local partition /vicepa RO = Site

 

Total = entries: 4

>> 

 

I’m unsure why there are duplicate RO = entries, but the last thing I was working on was recreating RO volumes for root.cell and root.afs on the new server. 

 

I’m panicking because all of the volumes are = now on the new server and non-accessible.  Anyone have some clue what I = did wrong and how I can fix things?

 

Thanks!

Karl

 

 

------=_NextPart_000_0081_01C805F5.3C9C6CF0-- From rra@stanford.edu Thu Oct 4 03:54:50 2007 From: rra@stanford.edu (Russ Allbery) Date: Wed, 03 Oct 2007 19:54:50 -0700 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <20071004021942.GA29067@copernico.tagus.ist.utl.pt> (Jose Calhariz's message of "Thu, 4 Oct 2007 03:19:42 +0100") References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> <87y7ek91tv.fsf@windlord.stanford.edu> <20071003103159.GA13953@copernico.tagus.ist.utl.pt> <87y7ekullc.fsf@windlord.stanford.edu> <20071004001122.GA5320@copernico.tagus.ist.utl.pt> <87bqbfvhet.fsf@windlord.stanford.edu> <20071004021942.GA29067@copernico.tagus.ist.utl.pt> Message-ID: <877im3twqt.fsf@windlord.stanford.edu> Jose Calhariz writes: > I don't know what happen. I have only two leads. One IO error > message from reiserfs on the begin of everything. And after the loss > I found a strange behavior with the hardware RAID5. I need to do > further investigation. > And most important I learned I don't know enough about reiserfs guts. > So I really don't understand the error messages from reiserfsck. I > will move into ext3, that I know very well, or XFS, I have a local > expert that can to help in case o trouble with XFS. The experience with a lot of people with ReiserFS is that it's great and fast until something goes wrong, and then it's a disaster. At this point, the file system also has a questionable future, and the kernel developers are leery of it. That's enough to make me want to go somewhere else for a file system. > I remember see an online presentation from an AFS workshop were XFS > was considered best than ext3 for /vicep partitions. My personal take on file systems is that smallish differentials in speed aren't worth worrying about compared to robustness and reliability, so I tend to run the most mainstream, most widely-used file system on whatever platform I'm using rather than try to squeeze a bit of additional peroformance by running something a bit more edgy. Right now, ext3 is the middle of the road and I think the safe choice. XFS is a lot better than ReiserFS, though, in terms of support and knowledge by the kernel developers, and would probably be fine. It is faster for a lot of usage profiles than ext3. > Thank you. I didn't know about that file. Documentation for CellAlias has been missing for a long time, but it's getting there slowly. > Ok, I have by default "ulimit -c 0". I don't depend on core files for > so many years I forget about ulimit -c 0. Now I am a sysadm not a > programmer. I only program in bash and install gdb for other people to > use, not for myself :-) Right. :) I got caught recently the same way, actually. > Thank you for your help on this issue. Certainly. I wish I knew more concrete details about what could have gone wrong. -- Russ Allbery (rra@stanford.edu) From cclausen@acm.org Thu Oct 4 04:18:33 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Wed, 3 Oct 2007 22:18:33 -0500 Subject: [OpenAFS] AFS Fileserver Won't Start References: <008001c8062f$e8fb44f0$baf1ced0$@com> Message-ID: <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> Karl M. Davis wrote: Hi Karl. I'm going to assume it was you in the #openafs IRC channel. I'd suggest staying logged in if you really want help. You have to wait for people to have time to respond. And more than the 15 minutes that you waited. We do need to do things like eat and sleep. > Somewhere towards the end of moving the volumes from the old server > to the new server, things got badly goofed. The fs process will no > longer start on the new server and I find the following entry in the > /var/log/openafs/FileLog file: > > Wed Oct 3 19:26:59 2007 afs_krb_get_lrealm failed, using > ridgetop-group.local. Is the above a correct assumption about your Realm? I would expect you to be using ridgetop-group.com. > Wed Oct 3 19:26:59 2007 VL_RegisterAddrs rpc failed; The IP address > exists on a different server; repair it Check the /etc/hosts file on all machines and all CellServDB files for incorrect entries. > Wed Oct 3 19:26:59 2007 VL_RegisterAddrs rpc failed; See VLLog for > details What is in VLLog? > Unfortunately, there's nothing helpful in VLLog. Interestingly, "vos > listaddrs" returns nothing on the new server, either. vos listaddrs might not be working b/c of the above errors. > Running "vos listvldb" returns the following: > VLDB entries for all servers > root.afs > RWrite: 536870915 ROnly: 536870916 > number of sites -> 3 > server picacho.ridgetop-group.local partition /vicepa RW Site > server picacho.ridgetop-group.local partition /vicepa RO Site > server picacho.ridgetop-group.local partition /vicepa RO Site > > root.cell > RWrite: 536870918 ROnly: 536870919 > number of sites -> 3 > server picacho.ridgetop-group.local partition /vicepa RW Site > server picacho.ridgetop-group.local partition /vicepa RO Site > server picacho.ridgetop-group.local partition /vicepa RO Site > > I'm unsure why there are duplicate RO entries, but the last thing I > was working on was recreating RO volumes for root.cell and root.afs > on the new server. Well, it looks like something did not work out right. > I'm panicking because all of the volumes are now on the new server and > non-accessible. Anyone have some clue what I did wrong and how I can > fix things? Probably going to need more information about what happened, what you did to try and fix it, and other infrastructure questions, like how many AFS DB servers you actually have, and if any of them are multi-homed. <<87y7ek91tv.fsf@windlord.stanford.edu><20071003103159.GA13953@copernico.tagus.ist.utl.pt><87y7ekullc.fsf@windlord.stanford.edu><20071004001122.GA5320@copernico.tagus.ist.utl.pt><87bqbfvhet.fsf@windlord.stanford.edu><20071004021942.GA29067@copernico.tagus.ist.utl.pt> <877im3twqt.fsf@windlord.stanford.edu> Message-ID: <43D540833712492D8306C0CAE020B4DE@CDCHOME> Russ Allbery wrote: > XFS is a lot better than ReiserFS, though, in terms of support and > knowledge by the kernel developers, and would probably be fine. It is > faster for a lot of usage profiles than ext3. I have had some problems with XFS on a Debian-based AFS fileserver. XFS decided to off-line a volume due to a long timeout in the underlying RAID volume. I would not recomend it without heavy testing. >> Ok, I have by default "ulimit -c 0". I don't depend on core files >> for so many years I forget about ulimit -c 0. Now I am a sysadm not >> a programmer. I only program in bash and install gdb for other >> people to use, not for myself :-) > > Right. :) I got caught recently the same way, actually. I'll note that someone mentioned a problem with the 8192 stack size in Debian a few months ago in the #openafs IRC channel. They worked around the problem with via changing some setting before starting the AFS processes. Unfortunately I do not remember the exact solution or the exact problem, but you are not the only one experiencing it. < References: <20071001175719.GA22026@copernico.tagus.ist.utl.pt> <87lkamg0ao.fsf@windlord.stanford.edu> <20071001183938.GA23003@copernico.tagus.ist.utl.pt> <20071001211438.GA27579@copernico.tagus.ist.utl.pt> <20071001230139.GA29588@nausicaa.cis.anl.gov> Message-ID: http://backuppc4afs.sourceforge.net/ It won't help with your current situation, but it does everything you want= =20 and is much easier to configure (via gui) than anything else I've seen. On Mon, 1 Oct 2007, Brian Sebby wrote: > I ended up writing a script to use the commmand 'vos dump' to dump each > AFS volume to a local disk partition, then back up that partition with > standard backup utilities. The 'vos dump' command creates a file on the > local disk that contains the entire volume, including all of the ACLs. > Since you can have links in AFS to the same volume multiple times, it's a > lot safer to do volume-based backups rather than walking AFS. > > I could get you a copy of my dump script if you're interested; I'd just > have to scrub out all of our site-specific information. > > > Brian > > On Mon, Oct 01, 2007 at 10:14:39PM +0100, Jose Calhariz wrote: >> On Mon, Oct 01, 2007 at 03:41:16PM -0400, Derek Atkins wrote: >>> Jose Calhariz writes: >>> >>>> On Mon, Oct 01, 2007 at 11:25:03AM -0700, Russ Allbery wrote: >>>>> Jose Calhariz writes: >>>>> >>>>>> I have lost a fileserver because of a corruption on the reiserfs v3. >>>>>> Something like 1000 volumes and 100GB of data were lost. The backups >>>>>> were made using amanda with standard tar. >>>>> >>>>>> My problem is the recovering of the data to the surviving filesystem >>>>>> is taking too much time. Something like 7 hours to recover 7 GB. >>>>>> Will I need 100hours to recover from tar 100GB? >>>>> >>>>> What did you tar up? I can think of a lot of possibilities (the raw = namei >>>>> filesystem, the contents of AFS archived with admin credentials, tarb= alls >>>>> of volume dumps), and the answer somewhat depends. >>>> >>>> I have tarballs with the contents of AFS using admin credentials. >>> >>> Note that you'll have to manually repair the acls; tar doesn't save >>> them. >> >> It's on my todo list, to find a command to export and import AFS >> acls. So it can be collected by tar. >> >>> >>> -derek >>> >> >> Jos=E9 Calhariz >> >> -- >> P.S. [En_US] The sig below is from my random sig-generator, which strang= ely >> often seems to pick signatures which are apropriate to the message at >> hand! >> >> P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de >> assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que >> parecem apropriadas ao email! >> -- >> Infeliz o povo que precisa de herois. >> -- Bertold Brecht > > > > --=20 > Brian Sebby (sebby@anl.gov) | Unix and Operation Services > Phone: +1 630.252.9935 | Computing and Information Systems > Fax: +1 630.252.4601 | Argonne National Laboratory > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > > --=20 > >= From karl@ridgetop-group.com Thu Oct 4 08:17:06 2007 From: karl@ridgetop-group.com (Karl M. Davis) Date: Thu, 4 Oct 2007 00:17:06 -0700 Subject: [OpenAFS] AFS Fileserver Won't Start In-Reply-To: <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> Message-ID: <000301c80656$92613f60$b723be20$@com> Thanks for the quick response, Yeah, sorry for disappearing there on IRC but I needed to restart the computer I was connected with. > Is the above a correct assumption about your Realm? I would expect you > to be using ridgetop-group.com. Yes, it is correct: our realm is ridgetop-group.local. > Check the /etc/hosts file on all machines and all CellServDB files for > incorrect entries. The CellServDB file is correct: /etc/openafs/CellServDB: << >ridgetop-group.local 192.168.2.5 # coronado.ridgetop-group.local 192.168.2.6 # picacho.ridgetop-group.local ... >> /etc/openafs/server/CellServDB: << >ridgetop-group.local #Cell name 192.168.2.5 #coronado.ridgetop-group.local 192.168.2.6 #picacho.ridgetop-group.local >> The /etc/hosts file is correct, but I did add the second line to it somewhere before things went to pot: << 127.0.0.1 localhost 192.168.2.6 picacho.ridgetop-group.local picacho 127.0.1.1 picacho.ridgetop-group.local picacho ... >> > What is in VLLog? Not much. /var/log/openafs/VLLog: << Wed Oct 3 23:45:05 2007 Using 192.168.2.6 as my primary address Wed Oct 3 23:45:05 2007 Starting AFS vlserver 4 (/usr/lib/openafs/vlserver) >> I believe that moving volumes went well enough. I started having trouble, though, when I went to recreate the RO copies of root.cell and root.afs. Unfortunately, I'm unclear on the exact order of all this now, but here's a list of the things I did: 1. Setup picacho as a dbserver and fileserver. 2. "vos move"'d all of the RW volumes from coronado to picacho. 3. "vos addsite"'s for root.afs and root.cell, but could not get "vos release" to work. It gave me some errors: "Failed to start a transaction on the RO volume ... volume is busy". 4. Tried "vos syncvldb" and "vos syncserv" on both servers, but those didn't seem to help. Running syncvldb on picacho gave me errors: "Warning: Orphaned RW volume ... exists on ...". 5. Further googling turned up some hits that suggested I should try "vos changeaddr 127.0.0.1 192.168.2.6". This is also around when I added the above-mentioned line to /etc/hosts. I can't recall exactly, but I may have tried playing around with "bos addhost" and "bos removehost" here as well. 6. Tried running "bos salvage". I'm pretty sure this is when things got ugly and fs stopped starting. Running "fs checkvolumes" now segfaults: very fun. I only have the two openafs servers: coronado (old VM) and picacho (new box). Both of them are dbservers and volservers, neither is multi-homed. That's the saga so far. I greatly appreciate any help you can offer! -- Karl -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Christopher D. Clausen Sent: Wednesday, October 03, 2007 8:19 PM To: Karl M. Davis Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] AFS Fileserver Won't Start Karl M. Davis wrote: Hi Karl. I'm going to assume it was you in the #openafs IRC channel. I'd suggest staying logged in if you really want help. You have to wait for people to have time to respond. And more than the 15 minutes that you waited. We do need to do things like eat and sleep. > Somewhere towards the end of moving the volumes from the old server > to the new server, things got badly goofed. The fs process will no > longer start on the new server and I find the following entry in the > /var/log/openafs/FileLog file: > > Wed Oct 3 19:26:59 2007 afs_krb_get_lrealm failed, using > ridgetop-group.local. Is the above a correct assumption about your Realm? I would expect you to be using ridgetop-group.com. > Wed Oct 3 19:26:59 2007 VL_RegisterAddrs rpc failed; The IP address > exists on a different server; repair it Check the /etc/hosts file on all machines and all CellServDB files for incorrect entries. > Wed Oct 3 19:26:59 2007 VL_RegisterAddrs rpc failed; See VLLog for > details What is in VLLog? > Unfortunately, there's nothing helpful in VLLog. Interestingly, "vos > listaddrs" returns nothing on the new server, either. vos listaddrs might not be working b/c of the above errors. > Running "vos listvldb" returns the following: > VLDB entries for all servers > root.afs > RWrite: 536870915 ROnly: 536870916 > number of sites -> 3 > server picacho.ridgetop-group.local partition /vicepa RW Site > server picacho.ridgetop-group.local partition /vicepa RO Site > server picacho.ridgetop-group.local partition /vicepa RO Site > > root.cell > RWrite: 536870918 ROnly: 536870919 > number of sites -> 3 > server picacho.ridgetop-group.local partition /vicepa RW Site > server picacho.ridgetop-group.local partition /vicepa RO Site > server picacho.ridgetop-group.local partition /vicepa RO Site > > I'm unsure why there are duplicate RO entries, but the last thing I > was working on was recreating RO volumes for root.cell and root.afs > on the new server. Well, it looks like something did not work out right. > I'm panicking because all of the volumes are now on the new server and > non-accessible. Anyone have some clue what I did wrong and how I can > fix things? Probably going to need more information about what happened, what you did to try and fix it, and other infrastructure questions, like how many AFS DB servers you actually have, and if any of them are multi-homed. < References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> Message-ID: <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> > > The /etc/hosts file is correct, but I did add the second line to it > somewhere before things went to pot: > << > 127.0.0.1 localhost > 192.168.2.6 picacho.ridgetop-group.local picacho > 127.0.1.1 picacho.ridgetop-group.local picacho I think you have to eliminate everything that resolves 127.something to picacho and the other way around. If you have managed to get 127.something into your volume database, all strange things may happen at once. Volumes located on 127.0.0.1 are perfectly fine accessible from 127.0.0.1 but of course from nowhere else. You may need to start over by deleting your sysid file. Harald. From karl@ridgetop-group.com Thu Oct 4 09:07:40 2007 From: karl@ridgetop-group.com (Karl M. Davis) Date: Thu, 4 Oct 2007 01:07:40 -0700 Subject: [OpenAFS] AFS Fileserver Won't Start In-Reply-To: <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> Message-ID: <000501c8065d$a2ae8290$e80b87b0$@com> Found the sysid file, removed it, and rebooted. Still have the same problems, though. Where might other entries be and how should I go about clearing them up? Thanks, Karl -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of haba@kth.se Sent: Thursday, October 04, 2007 12:42 AM To: Karl M. Davis Cc: openafs-info@openafs.org Subject: RE: [OpenAFS] AFS Fileserver Won't Start > > The /etc/hosts file is correct, but I did add the second line to it > somewhere before things went to pot: > << > 127.0.0.1 localhost > 192.168.2.6 picacho.ridgetop-group.local picacho > 127.0.1.1 picacho.ridgetop-group.local picacho I think you have to eliminate everything that resolves 127.something to picacho and the other way around. If you have managed to get 127.something into your volume database, all strange things may happen at once. Volumes located on 127.0.0.1 are perfectly fine accessible from 127.0.0.1 but of course from nowhere else. You may need to start over by deleting your sysid file. Harald. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From karl@ridgetop-group.com Thu Oct 4 11:26:17 2007 From: karl@ridgetop-group.com (Karl M. Davis) Date: Thu, 4 Oct 2007 03:26:17 -0700 Subject: [OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs In-Reply-To: <000501c8065d$a2ae8290$e80b87b0$@com> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> Message-ID: <000001c80671$002a9180$007fb480$@com> Well, after rebooting again, things suddenly seem to be working. No idea why... I still have some problems with making RO copies of root.cell and root.afs, though. Running "vos release" gives me: << karl@picacho:~$ vos release -id root.cell Failed to start a transaction on the RO volume. VOLSER: volume is busy The volume 536870918 could not be released to the following 1 sites: picacho.ridgetop-group.local /vicepa VOLSER: release could not be completed Error in vos release command. VOLSER: release could not be completed karl@picacho:~$ vos release -id root.afs Failed to start a transaction on the RO volume. VOLSER: volume is busy The volume 536870915 could not be released to the following 1 sites: picacho.ridgetop-group.local /vicepa VOLSER: release could not be completed Error in vos release command. VOLSER: release could not be completed >> And in /var/log/openafs/VolserLog, there's this: << ... Thu Oct 4 02:59:21 2007 1 Volser: Clone: Recloning volume 536870918 to volume 536870919 Thu Oct 4 02:59:26 2007 1 transcreate: can't create transaction Thu Oct 4 02:59:32 2007 1 Volser: Clone: Recloning volume 536870915 to volume 536870916 Thu Oct 4 02:59:37 2007 1 transcreate: can't create transaction >> Before I get myself into trouble again with wild guessing, does anyone know how I'm SUPPOSED to fix this? Thanks! Karl -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Karl M. Davis Sent: Thursday, October 04, 2007 1:08 AM To: haba@kth.se Cc: openafs-info@openafs.org Subject: RE: [OpenAFS] AFS Fileserver Won't Start Found the sysid file, removed it, and rebooted. Still have the same problems, though. Where might other entries be and how should I go about clearing them up? Thanks, Karl -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of haba@kth.se Sent: Thursday, October 04, 2007 12:42 AM To: Karl M. Davis Cc: openafs-info@openafs.org Subject: RE: [OpenAFS] AFS Fileserver Won't Start > > The /etc/hosts file is correct, but I did add the second line to it > somewhere before things went to pot: > << > 127.0.0.1 localhost > 192.168.2.6 picacho.ridgetop-group.local picacho > 127.0.1.1 picacho.ridgetop-group.local picacho I think you have to eliminate everything that resolves 127.something to picacho and the other way around. If you have managed to get 127.something into your volume database, all strange things may happen at once. Volumes located on 127.0.0.1 are perfectly fine accessible from 127.0.0.1 but of course from nowhere else. You may need to start over by deleting your sysid file. Harald. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From jason@rampaginggeek.com Thu Oct 4 13:59:09 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Thu, 04 Oct 2007 08:59:09 -0400 Subject: [OpenAFS] fileserver on etch may crash because ulimit -s 8192 In-Reply-To: <877im3twqt.fsf@windlord.stanford.edu> References: <20071002195550.GA3549@copernico.tagus.ist.utl.pt> <87y7ek91tv.fsf@windlord.stanford.edu> <20071003103159.GA13953@copernico.tagus.ist.utl.pt> <87y7ekullc.fsf@windlord.stanford.edu> <20071004001122.GA5320@copernico.tagus.ist.utl.pt> <87bqbfvhet.fsf@windlord.stanford.edu> <20071004021942.GA29067@copernico.tagus.ist.utl.pt> <877im3twqt.fsf@windlord.stanford.edu> Message-ID: <4704E39D.4050600@rampaginggeek.com> Russ Allbery wrote: > Jose Calhariz writes: > >> Thank you. I didn't know about that file. >> > > Documentation for CellAlias has been missing for a long time, but it's > getting there slowly. > CellAlias is now documented. I wrote the man page myself. It's in CVS and available at the following web address: http://www.openafs.org/cgi-bin/cvsweb.cgi/openafs/doc/man-pages/pod5/CellAlias.pod?rev=1.3&content-type=text/x-cvsweb-markup I did it a few months ago and it should be included in any new Openafs releases. There is more documentation in the pipeline as well. Jason From cclausen@acm.org Thu Oct 4 14:45:37 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Thu, 4 Oct 2007 08:45:37 -0500 Subject: [OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> Message-ID: <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> Karl M. Davis wrote: > Well, after rebooting again, things suddenly seem to be working. No > idea why... > > I still have some problems with making RO copies of root.cell and > root.afs, though. Running "vos release" gives me: > << > karl@picacho:~$ vos release -id root.cell > Failed to start a transaction on the RO volume. > VOLSER: volume is busy > The volume 536870918 could not be released to the following 1 sites: > picacho.ridgetop-group.local /vicepa > VOLSER: release could not be completed > Error in vos release command. > VOLSER: release could not be completed > karl@picacho:~$ vos release -id root.afs > Failed to start a transaction on the RO volume. > VOLSER: volume is busy > The volume 536870915 could not be released to the following 1 sites: > picacho.ridgetop-group.local /vicepa > VOLSER: release could not be completed > Error in vos release command. > VOLSER: release could not be completed Try vos release -id root.afs -verbose -local as root to get more info and use your KeyFile instead of user tokens. Does vos listaddrs -noresolve print out? And can you vos changeaddr -remove any incorrect IP addresses? (You might need to vos remsite replicas attached to those IPs first.) You might still be having problems related to having your 127.* /etc/hosts line match the actual IP of your AFS server. In theory you can shutdown both AFS servers, delete your VL DB and have it regenerated via vos syncserv and vos syncvldb commands. Of course, this could also make things worse. < References: <002901c73e2f$a622c4f0$1e00a8c0@delllaptop> <004e01c73e36$ca69b5b0$24c7ea83@delllaptop> <45B4D424.7020303@secure-endpoints.com> Message-ID: <47050A58.9020401@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms000609010304060102030307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This was caused by a bug in KFW's Credential Cache API implementation. It will be fixed in KFW 3.2.2 to be released later this month. Jeffrey Altman --------------ms000609010304060102030307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMDQxNTQ0MjRaMCMGCSqGSIb3DQEJBDEWBBQepKGn IMM9q1m2mEY4Z2KZoYJLxTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAQn329jrmnsEJEAA9mnc4D3YpxfCj5kPwYlWZLVJBkEWUfWnA5+uX 9eFYyttszOd6DqznMB9WNDtpTuLdjimcgQeIw3FuNgny/DOw0Li/dnF8hWfD0Rzkk48T6V4U FYRdZeiMHXspr0e2rN62iB/0AlK+MOrtR90ZGxm8APvThRLpEZQDfMKdjoWuSAW2ZJ7OlaBH wK+eo2VFsFUXurg96gAH3OGqkNnPG6XAr+6YATBMA5/FT1LLxNYUqUWkEUdrfHp7obCT2YUh MA52ZxBqQXGVtbrES5SZEHFa2T1glXIWaY4sbKNJJDv0T3PGuhmWqUlZzwsVtsWASa8JN3w5 7gAAAAAAAA== --------------ms000609010304060102030307-- From jaltman@secure-endpoints.com Thu Oct 4 17:00:50 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 04 Oct 2007 12:00:50 -0400 Subject: [OpenAFS] Seeking matching funds for OpenAFS Server work on Microsoft Windows Message-ID: <47050E32.7090301@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms050102060101000807090804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Microsoft is considering contributing funds to support and development of the OpenAFS Servers on the Microsoft Windows Server platform. For a description of the proposed project see: http://www.secure-endpoints.com/openafs-windows-roadmap.html#afs%20servers Microsoft is considering a contribution of approximately 1/4th of the project or $25,000. I am seeking organizations that would be interested in funding or contributing code for the other 3/4ths. In addition, Microsoft would provide technical assistance from the Windows Storage team. The goal would be to have working AFS Servers on Windows Server for the second quarter of 2008 with Active Directory integration, Management Console snap-ins and installation wizards completed in the second half of 2008. One of the most important aspects of this project is that it would establish a formal relationship between Microsoft and Secure Endpoints Inc. in support of OpenAFS on Microsoft Windows. It would remove much of the fear, uncertainty and doubt surrounding the OpenAFS community's ability to maintain compatibility with future Microsoft Windows platforms. If your organization would be interested in seeing supporting this project, please contact me. Jeffrey Altman Secure Endpoints Inc. --------------ms050102060101000807090804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMDQxNjAwNTBaMCMGCSqGSIb3DQEJBDEWBBRIcQab sEs+oZMayFQPi0afp0SNKzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAXINkVfNTU7cdBypLKIigY8wcZ6AEEzbE2rmTL/fP+7mKd9W2DNpM 9XWwk7uMjEMTtuhHc0bwsRMU00NDD+szf8lhrNNjpctvhoILW4+jT7vIpRal3KeNPfsEWdFt nK59OI80u5h79eyL9nbU9Tj2IZc0f2TT2xWL4QzL/+7IT1RvwctTzrA5S9YHP25WC64yTrOt KHrF3A2nO2GQv0wu7ZN92XxhqAlkxJN92OmoQJIKMNj8o19GGWuuE2VHLh4jVQqtMf/d4s5X EIaYUsb3c0t5NFfXaIGoQnEWXp5eIHbsQ/gAfyeB/oViAtGFQqb/sSmEKm9AbP8A4vY8cFoq kwAAAAAAAA== --------------ms050102060101000807090804-- From shadow@gmail.com Thu Oct 4 17:16:18 2007 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 4 Oct 2007 12:16:18 -0400 Subject: [OpenAFS] AFS Fileserver Won't Start In-Reply-To: <000501c8065d$a2ae8290$e80b87b0$@com> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> Message-ID: ------=_Part_11535_6928903.1191514578254 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Well, what does vos listaddrs tell you? On 10/4/07, Karl M. Davis wrote: > > Found the sysid file, removed it, and rebooted. Still have the same > problems, though. > > Where might other entries be and how should I go about clearing them up? > > Thanks, > Karl > > > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto: > openafs-info-admin@openafs.org] > On Behalf Of haba@kth.se > Sent: Thursday, October 04, 2007 12:42 AM > To: Karl M. Davis > Cc: openafs-info@openafs.org > Subject: RE: [OpenAFS] AFS Fileserver Won't Start > > > > > The /etc/hosts file is correct, but I did add the second line to it > > somewhere before things went to pot: > > << > > 127.0.0.1 localhost > > 192.168.2.6 picacho.ridgetop-group.local picacho > > 127.0.1.1 picacho.ridgetop-group.local picacho > > I think you have to eliminate everything that resolves > 127.something to picacho and the other way around. If you > have managed to get 127.something into your volume database, > all strange things may happen at once. > > Volumes located on 127.0.0.1 are perfectly fine accessible > from 127.0.0.1 but of course from nowhere else. > > You may need to start over by deleting your sysid file. > > Harald. > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > ------=_Part_11535_6928903.1191514578254 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Well, what does vos listaddrs tell you?

On 10/4/07, Karl M. Davis <karl@ridgetop-group.com> wrote:
Found the sysid file, removed it, and rebooted.  Still have the same
problems, though.

Where might other entries be and how should I go about clearing them up?

Thanks,
Karl


-----Original Message-----
From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]
On Behalf Of haba@kth.se
Sent: Thursday, October 04, 2007 12:42 AM
To: Karl M. Davis
Cc: openafs-info@openafs.org
Subject: RE: [OpenAFS] AFS Fileserver Won't Start

>
> The /etc/hosts file is correct, but I did add the second line to it
> somewhere before things went to pot:
> <<
> 127.0.0.1       localhost
> 192.168.2.6     picacho.ridgetop-group.local    picacho
> 127.0.1.1       picacho.ridgetop-group.local    picacho

I think you have to eliminate everything that resolves
127.something to picacho and the other way around. If you
have managed to get 127.something into your volume database,
all strange things may happen at once.

Volumes located on 127.0.0.1 are perfectly fine accessible
from 127.0.0.1 but of course from nowhere else.

You may need to start over by deleting your sysid file.

Harald.


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


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

------=_Part_11535_6928903.1191514578254-- From karl@ridgetop-group.com Fri Oct 5 01:14:53 2007 From: karl@ridgetop-group.com (Karl M. Davis) Date: Thu, 4 Oct 2007 17:14:53 -0700 Subject: [OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs In-Reply-To: <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> Message-ID: <00bf01c806e4$c11ecaf0$435c60d0$@com> > Try vos release -id root.afs -verbose -local as root to get more info > and use your KeyFile instead of user tokens.Running that command gives me: << karl@picacho:~$ sudo vos release -id root.afs -verbose -localauth root.afs RWrite: 536870915 ROnly: 536870916 RClone: 536870916 number of sites -> 4 server picacho.ridgetop-group.local partition /vicepa RW Site -- New release server picacho.ridgetop-group.local partition /vicepa RO Site -- New release server picacho.ridgetop-group.local partition /vicepa RO Site -- Old release server coronado.ridgetop-group.local partition /vicepa RO Site -- New release This is a completion of a previous release Starting transaction on cloned volume 536870916... done Failed to start a transaction on the RO volume. VOLSER: volume is busy The volume 536870915 could not be released to the following 1 sites: picacho.ridgetop-group.local /vicepa VOLSER: release could not be completed Error in vos release command. VOLSER: release could not be completed karl@picacho:~$ >> > Does vos listaddrs -noresolve print out? Nope, nothing from that, either. > You might need to vos remsite replicas attached to those IPs first. Interesting... I tried this but instead of specifying picacho, I passed it 127.0.0.1 as the machine name and it worked. It actually worked twice for each. Here's the output: << karl@picacho:~$ sudo vos remsite -server 127.0.0.1 -partition a -id root.afs -localauth -verbose Deleting the replication site for volume 536870915 ... done Removed replication site 127.0.0.1 /vicepa for volume root.afs karl@picacho:~$ sudo vos remsite -server 127.0.0.1 -partition a -id root.afs -localauth -verbose Deleting the replication site for volume 536870915 ... done Removed replication site 127.0.0.1 /vicepa for volume root.afs karl@picacho:~$ sudo vos remsite -server 127.0.0.1 -partition a -id root.afs -localauth -verbose This site is not a replication site Error in vos remsite command. VOLSER: illegal operation karl@picacho:~$ vos listvldb vsu_ClientInit: Could not get afs tokens, running unauthenticated. VLDB entries for all servers lib RWrite: 536870933 ROnly: 536870934 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site lib.pdks RWrite: 536870936 ROnly: 536870937 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site root.afs RWrite: 536870915 ROnly: 536870916 RClone: 536870916 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site -- New release server coronado.ridgetop-group.local partition /vicepa RO Site -- New release root.cell RWrite: 536870918 ROnly: 536870919 RClone: 536870919 number of sites -> 4 server picacho.ridgetop-group.local partition /vicepa RW Site -- New release server picacho.ridgetop-group.local partition /vicepa RO Site -- New release server picacho.ridgetop-group.local partition /vicepa RO Site -- Old release server coronado.ridgetop-group.local partition /vicepa RO Site -- New release Total entries: 4 karl@picacho:~$ sudo vos remsite -server 127.0.0.1 -partition a -id root.cell -localauth -verbose Deleting the replication site for volume 536870918 ... done Removed replication site 127.0.0.1 /vicepa for volume root.cell karl@picacho:~$ sudo vos remsite -server 127.0.0.1 -partition a -id root.cell -localauth -verbose Deleting the replication site for volume 536870918 ... done Removed replication site 127.0.0.1 /vicepa for volume root.cell karl@picacho:~$ sudo vos remsite -server 127.0.0.1 -partition a -id root.cell -localauth -verbose This site is not a replication site Error in vos remsite command. VOLSER: illegal operation karl@picacho:~$ vos listvldb vsu_ClientInit: Could not get afs tokens, running unauthenticated. VLDB entries for all servers lib RWrite: 536870933 ROnly: 536870934 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site lib.pdks RWrite: 536870936 ROnly: 536870937 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site root.afs RWrite: 536870915 ROnly: 536870916 RClone: 536870916 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site -- New release server coronado.ridgetop-group.local partition /vicepa RO Site -- New release root.cell RWrite: 536870918 ROnly: 536870919 RClone: 536870919 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site -- New release server coronado.ridgetop-group.local partition /vicepa RO Site -- New release Total entries: 4 >> After that, I tried "vos release" again. Here's the output from that: << karl@picacho:~$ sudo vos release -id root.cell -verbose -localauth root.cell RWrite: 536870918 ROnly: 536870919 RClone: 536870919 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site -- New release server coronado.ridgetop-group.local partition /vicepa RO Site -- New release This is a complete release of volume 536870918 Cloning RW volume 536870918 to temporary RO... done Getting status of RW volume 536870918... done Ending cloning transaction on RW volume 536870918... done Starting transaction on cloned volume 536870919... done Updating existing ro volume 536870919 on coronado.ridgetop-group.local ... Starting ForwardMulti from 536870919 to 536870919 on coronado.ridgetop-group.local (as of Thu Sep 6 12:58:39 2007). Deleting the releaseClone 536870919 ... done updating VLDB ... done Released volume root.cell successfully karl@picacho:~$ vos listvldb vsu_ClientInit: Could not get afs tokens, running unauthenticated. VLDB entries for all servers lib RWrite: 536870933 ROnly: 536870934 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site lib.pdks RWrite: 536870936 ROnly: 536870937 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site root.afs RWrite: 536870915 ROnly: 536870916 RClone: 536870916 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site -- New release server coronado.ridgetop-group.local partition /vicepa RO Site -- New release root.cell RWrite: 536870918 ROnly: 536870919 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site Total entries: 4 karl@picacho:~$ sudo vos release -id root.afs -verbose -localauth root.afs RWrite: 536870915 ROnly: 536870916 RClone: 536870916 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site -- New release server coronado.ridgetop-group.local partition /vicepa RO Site -- New release This is a complete release of volume 536870915 Cloning RW volume 536870915 to temporary RO... done Getting status of RW volume 536870915... done Ending cloning transaction on RW volume 536870915... done Starting transaction on cloned volume 536870916... done Updating existing ro volume 536870916 on coronado.ridgetop-group.local ... Starting ForwardMulti from 536870916 to 536870916 on coronado.ridgetop-group.local (as of Thu Aug 9 13:13:33 2007). Deleting the releaseClone 536870916 ... done updating VLDB ... done Released volume root.afs successfully karl@picacho:~$ vos listvldb vsu_ClientInit: Could not get afs tokens, running unauthenticated. VLDB entries for all servers lib RWrite: 536870933 ROnly: 536870934 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site lib.pdks RWrite: 536870936 ROnly: 536870937 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site root.afs RWrite: 536870915 ROnly: 536870916 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site root.cell RWrite: 536870918 ROnly: 536870919 number of sites -> 2 server picacho.ridgetop-group.local partition /vicepa RW Site server coronado.ridgetop-group.local partition /vicepa RO Site Total entries: 4 >> I then tried running "vos changeaddr -oldaddr 127.0.0.1 -remove", but it looks like some of my volumes are still "stuck" on the old IP: << karl@picacho:~$ sudo vos changeaddr -oldaddr 127.0.0.1 -remove -localauth -verbose Could not remove server 127.0.0.1 from the VLDB VLDB: volume Id exists in the vldb >> How would I go about resolving this? By the way, thanks very much for all of your help so far; you've really saved my ass on this. Thanks, Karl -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Christopher D. Clausen Sent: Thursday, October 04, 2007 6:46 AM To: Karl M. Davis Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs Karl M. Davis wrote: > Well, after rebooting again, things suddenly seem to be working. No > idea why... > > I still have some problems with making RO copies of root.cell and > root.afs, though. Running "vos release" gives me: > << > karl@picacho:~$ vos release -id root.cell > Failed to start a transaction on the RO volume. > VOLSER: volume is busy > The volume 536870918 could not be released to the following 1 sites: > picacho.ridgetop-group.local /vicepa > VOLSER: release could not be completed > Error in vos release command. > VOLSER: release could not be completed > karl@picacho:~$ vos release -id root.afs > Failed to start a transaction on the RO volume. > VOLSER: volume is busy > The volume 536870915 could not be released to the following 1 sites: > picacho.ridgetop-group.local /vicepa > VOLSER: release could not be completed > Error in vos release command. > VOLSER: release could not be completed Try vos release -id root.afs -verbose -local as root to get more info and use your KeyFile instead of user tokens. Does vos listaddrs -noresolve print out? And can you vos changeaddr -remove any incorrect IP addresses? (You might need to vos remsite replicas attached to those IPs first.) You might still be having problems related to having your 127.* /etc/hosts line match the actual IP of your AFS server. In theory you can shutdown both AFS servers, delete your VL DB and have it regenerated via vos syncserv and vos syncvldb commands. Of course, this could also make things worse. < Can't Release root.cell or root.afs References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> <00bf01c806e4$c11ecaf0$435c60d0$@com> Message-ID: <438C4BA5882E416FA77A1A7933A14E31@CDCHOME> Karl M. Davis wrote: > I then tried running "vos changeaddr -oldaddr 127.0.0.1 -remove", but > it looks like some of my volumes are still "stuck" on the old IP: > > karl@picacho:~$ sudo vos changeaddr -oldaddr 127.0.0.1 -remove > -localauth -verbose > Could not remove server 127.0.0.1 from the VLDB > VLDB: volume Id exists in the vldb I'd say to try and get a good vos dump of each volume that you care about so that you can at least restore to a new cell if things go bad from here. Usually I'd fix this finding the volume that is listed as being on that IP and moving it to another server :-) But it would seem that you have already done that. I guess its possible that the vldb still thinks that 127.0.0.1 is one of the servers somehow. Did you try restarting your file servers? Does vos syncvldb/syncserv do anything useful for you? If not, it should be safe to shutdown the AFS server and delete the VL db files and have them get recreated at server startup. (Might need to delete the sysid file as well.) Or, vos dumping, deleting, and recreate each volume via vos restore may fix it, assuming you have fixed all 127.0.0.1 problems. > How would I go about resolving this? By the way, thanks very much > for all of your help so far; you've really saved my ass on this. No problem. I'm glad it helped. < Can't Release root.cell or root.afs In-Reply-To: <31840886.1191560299507.JavaMail.root@m11> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> <00bf01c806e4$c11ecaf0$435c60d0$@com> <31840886.1191560299507.JavaMail.root@m11> Message-ID: <470636FB.40706@ccre.com> Have you tried changeaddr from 127.0.0.1 to <whatever the IP address of server is> ??

You might also try
vos remove <server> <partition> <volumename>.readonly     #for each readonly instance
vos backup <volumename>
vos dump <volumename>.backup | vos restore <server> <partition> <volumename> -overwrite full

Use the same volume name for each instance of <volumename>

This will give you a new volumeID for <volumename> which will be reflected in the VLDB.
Then "vos addsite" to replace the RO sites.
Then "vos release"

Kim

Christopher D. Clausen wrote: 
Karl M. Davis <karl@ridgetop-group.com> wrote:
  
I then tried running "vos changeaddr -oldaddr 127.0.0.1 -remove", but
it looks like some of my volumes are still "stuck" on the old IP:

karl@picacho:~$ sudo vos changeaddr -oldaddr 127.0.0.1 -remove
-localauth -verbose
Could not remove server 127.0.0.1 from the VLDB
VLDB: volume Id exists in the vldb
    

I'd say to try and get a good vos dump of each volume that you care 
about so that you can at least restore to a new cell if things go bad 
from here.

Usually I'd fix this finding the volume that is listed as being on that 
IP and moving it to another server :-)  But it would seem that you have 
already done that.  I guess its possible that the vldb still thinks that 
127.0.0.1 is one of the servers somehow.  Did you try restarting your 
file servers?

Does vos syncvldb/syncserv do anything useful for you?  If not, it 
should be safe to shutdown the AFS server and delete the VL db files and 
have them get recreated at server startup.  (Might need to delete the 
sysid file as well.)

Or, vos dumping, deleting, and recreate each volume via vos restore may 
fix it, assuming you have fixed all 127.0.0.1 problems.

  
How would I go about resolving this?  By the way, thanks very much
for all of your help so far; you've really saved my ass on this.
    

No problem.  I'm glad it helped.

<<CDC 


_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
From cclausen@acm.org Fri Oct 5 14:16:42 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Fri, 5 Oct 2007 08:16:42 -0500 Subject: [OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> <00bf01c806e4$c11ecaf0$435c60d0$@com> <31840886.1191560299507.JavaMail.root@m11> <470636FB.40706@ccre.com> Message-ID: <1A125B36A0834D529EEEE0E2DBCC6DCE@CDCHOME> Kim Kimball wrote: > You might also try > vos remove .readonly #for each > readonly instance > vos backup > vos dump .backup | vos restore > -overwrite full > > Use the same volume name for each instance of > > This will give you a new volumeID for which will be > reflected in the VLDB. Then "vos addsite" to replace the RO sites. > Then "vos release" I was going to suggest that, but I figured it may not actually clear up the problem and could potentially just waste a lot of time. How does one know that the 127.* IPs really are gone? ----- When specifing server names, DO NOT use "localhost" or "127.0.0.1." Use the FQDNs of your servers. ----- Hmm... would vos delent for each volume, then the vos changeaddr -remove, and then a vos syncvldb do the same thing and not take as much time for the dump / restores? < Can't Release root.cell or root.afs In-Reply-To: <438C4BA5882E416FA77A1A7933A14E31@CDCHOME> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> <00bf01c806e4$c11ecaf0$435c60d0$@com> <438C4BA5882E416FA77A1A7933A14E31@CDCHOME> Message-ID: ------=_Part_13769_6516903.1191590610052 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline There was a bug in some older OpenAFS that would let 127.0.0.1 be advertised. If you're not running something modern, upgrade. Anyway, you can also put 127.0.0.1 in the NetRestrict file and restart, masking it out from the list of advertised addresses. On 10/5/07, Christopher D. Clausen wrote: > > Karl M. Davis wrote: > > I then tried running "vos changeaddr -oldaddr 127.0.0.1 -remove", but > > it looks like some of my volumes are still "stuck" on the old IP: > > > > karl@picacho:~$ sudo vos changeaddr -oldaddr 127.0.0.1 -remove > > -localauth -verbose > > Could not remove server 127.0.0.1 from the VLDB > > VLDB: volume Id exists in the vldb > > I'd say to try and get a good vos dump of each volume that you care > about so that you can at least restore to a new cell if things go bad > from here. > > Usually I'd fix this finding the volume that is listed as being on that > IP and moving it to another server :-) But it would seem that you have > already done that. I guess its possible that the vldb still thinks that > 127.0.0.1 is one of the servers somehow. Did you try restarting your > file servers? > > Does vos syncvldb/syncserv do anything useful for you? If not, it > should be safe to shutdown the AFS server and delete the VL db files and > have them get recreated at server startup. (Might need to delete the > sysid file as well.) > > Or, vos dumping, deleting, and recreate each volume via vos restore may > fix it, assuming you have fixed all 127.0.0.1 problems. > > > How would I go about resolving this? By the way, thanks very much > > for all of your help so far; you've really saved my ass on this. > > No problem. I'm glad it helped. > > < > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > ------=_Part_13769_6516903.1191590610052 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline There was a bug in some older OpenAFS that would let 127.0.0.1 be advertised. If you're not running something modern, upgrade.

Anyway, you can also put 127.0.0.1 in the NetRestrict file and restart, masking it out from the list of advertised addresses.



On 10/5/07, Christopher D. Clausen < cclausen@acm.org> wrote:
Karl M. Davis < karl@ridgetop-group.com> wrote:
> I then tried running "vos changeaddr -oldaddr 127.0.0.1 -remove", but
> it looks like some of my volumes are still "stuck" on the old IP:
>
> karl@picacho:~$ sudo vos changeaddr -oldaddr 127.0.0.1 -remove
> -localauth -verbose
> Could not remove server 127.0.0.1 from the VLDB
> VLDB: volume Id exists in the vldb

I'd say to try and get a good vos dump of each volume that you care
about so that you can at least restore to a new cell if things go bad
from here.

Usually I'd fix this finding the volume that is listed as being on that
IP and moving it to another server :-)  But it would seem that you have
already done that.  I guess its possible that the vldb still thinks that
127.0.0.1 is one of the servers somehow.  Did you try restarting your
file servers?

Does vos syncvldb/syncserv do anything useful for you?  If not, it
should be safe to shutdown the AFS server and delete the VL db files and
have them get recreated at server startup.  (Might need to delete the
sysid file as well.)

Or, vos dumping, deleting, and recreate each volume via vos restore may
fix it, assuming you have fixed all 127.0.0.1 problems.

> How would I go about resolving this?  By the way, thanks very much
> for all of your help so far; you've really saved my ass on this.

No problem.  I'm glad it helped.

<<CDC


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

------=_Part_13769_6516903.1191590610052-- From shadow@gmail.com Fri Oct 5 14:27:58 2007 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 5 Oct 2007 09:27:58 -0400 Subject: [OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs In-Reply-To: <1A125B36A0834D529EEEE0E2DBCC6DCE@CDCHOME> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> <00bf01c806e4$c11ecaf0$435c60d0$@com> <31840886.1191560299507.JavaMail.root@m11> <470636FB.40706@ccre.com> <1A125B36A0834D529EEEE0E2DBCC6DCE@CDCHOME> Message-ID: ------=_Part_13782_25848326.1191590878428 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/5/07, Christopher D. Clausen wrote: > > Kim Kimball wrote: > > You might also try > > vos remove .readonly #for each > > readonly instance > > vos backup > > vos dump .backup | vos restore > > -overwrite full > > > > Use the same volume name for each instance of > > > > This will give you a new volumeID for which will be > > reflected in the VLDB. Then "vos addsite" to replace the RO sites. > > Then "vos release" > > I was going to suggest that, but I figured it may not actually clear up > the problem and could potentially just waste a lot of time. > > How does one know that the 127.* IPs really are gone? vos listvl? ----- > > When specifing server names, DO NOT use "localhost" or "127.0.0.1." Use > the FQDNs of your servers. > > ----- > > Hmm... would vos delent for each volume, then the vos > changeaddr -remove, and then a vos syncvldb do the same thing and not > take as much time for the dump / restores? even if changeaddr -remove fails, you can changeaddr to a bogus address, listvl and delent for the bogus address, then syncvldb. at worst you have an orphan address in the vldb that no one is going to care about. ------=_Part_13782_25848326.1191590878428 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/5/07, Christopher D. Clausen <cclausen@acm.org> wrote:
Kim Kimball <dhk@ccre.com> wrote:
> You might also try
> vos remove <server> <partition> <volumename>.readonly     #for each
> readonly instance
> vos backup <volumename>
> vos dump <volumename>.backup | vos restore <server> <partition>
> <volumename> -overwrite full
>
> Use the same volume name for each instance of <volumename>
>
> This will give you a new volumeID for <volumename> which will be
> reflected in the VLDB. Then "vos addsite" to replace the RO sites.
> Then "vos release"

I was going to suggest that, but I figured it may not actually clear up
the problem and could potentially just waste a lot of time.

How does one know that the 127.* IPs really are gone?

vos listvl?
 

-----

When specifing server names, DO NOT use "localhost" or "127.0.0.1."  Use
the FQDNs of your servers.

-----

Hmm... would vos delent for each volume, then the vos
changeaddr -remove, and then a vos syncvldb do the same thing and not
take as much time for the dump / restores?

even if changeaddr -remove fails, you can changeaddr to a bogus address, listvl and delent for the bogus address, then syncvldb. at worst you have an orphan address in the vldb that no one is going to care about.




------=_Part_13782_25848326.1191590878428-- From hans@MPA-Garching.MPG.DE Fri Oct 5 14:46:49 2007 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Fri, 5 Oct 2007 15:46:49 +0200 Subject: [OpenAFS] gcc-4.2.1, afs-client not working Message-ID: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> Hello, on i386_linux26 I compiled the kernel 2.6.22.9 and OpenAFS 1.4.4 using the gcc 4.2.1. Now I get: =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D # ls -l /afs=20 ls: cannot access /afs/mpa-garching.mpg.de: No such file or directory ls: cannot access /afs/ipp-garching.mpg.de: No such file or directory ls: cannot access /afs/world: No such file or directory ls: cannot access /afs/rzg.mpg.de: No such file or directory ls: cannot access /afs/andrew.cmu.edu: No such file or directory total 14 d????????? ? ? ? ? ? andrew.cmu.edu drwxr-xr-x 11 root root 6144 Sep 21 07:18 ipp ?????????? ? ? ? ? ? ipp-garching.mpg.de drwxr-xr-x 3 root root 2048 Mar 30 2007 mpa ?????????? ? ? ? ? ? mpa-garching.mpg.de drwxr-xr-x 11 root root 6144 Sep 21 07:18 rzg d????????? ? ? ? ? ? rzg.mpg.de ?????????? ? ? ? ? ? world =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D When I recompiled the OpenAFS software using gcc 4.1.2 everything is fine. Any idea or help? Hans-Werner --=20 Hans-Werner Paulsen hans@MPA-Garching.MPG.DE MPI f=FCr Astrophysik Tel 089-30000-2602 Karl-Schwarzschild-Str. 1 Fax 089-30000-2235=09 D-85741 Garching From dhk@ccre.com Fri Oct 5 14:55:53 2007 From: dhk@ccre.com (Kim Kimball) Date: Fri, 05 Oct 2007 07:55:53 -0600 Subject: *** Spam *** Re: [OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs In-Reply-To: <25812085.1191590023472.JavaMail.root@m11> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> <00bf01c806e4$c11ecaf0$435c60d0$@com> <31840886.1191560299507.JavaMail.root@m11> <25812085.1191590023472.JavaMail.root@m11> Message-ID: <47064269.4070900@ccre.com> Thought of two other things you might try.

1. Use "vos delentry" to remove VLDB entries, followed by "vos syncvldb" to recreate entries.
2. Shut down the VLservers, delete the VLDB db files from each DB server (/usr/afs/db/vldb.DB0 & /usr/afs/db/vldb.DBSYS1), start the VLservers again, wait for quorum, and "vos syncvldb" on servers

As long as 127.0.0.1 is not the 'primary' IP for any file server the recreated VLDB entries should have no loopback reference.

Method 2 is probably the more definitive approach.

Kim


Kim Kimball wrote:
Have you tried changeaddr from 127.0.0.1 to <whatever the IP address of server is> ??

You might also try
vos remove <server> <partition> <volumename>.readonly     #for each readonly instance
vos backup <volumename>
vos dump <volumename>.backup | vos restore <server> <partition> <volumename> -overwrite full

Use the same volume name for each instance of <volumename>

This will give you a new volumeID for <volumename> which will be reflected in the VLDB.
Then "vos addsite" to replace the RO sites.
Then "vos release"

Kim

Christopher D. Clausen wrote: 
Karl M. Davis <karl@ridgetop-group.com> wrote:
  
I then tried running "vos changeaddr -oldaddr 127.0.0.1 -remove", but
it looks like some of my volumes are still "stuck" on the old IP:

karl@picacho:~$ sudo vos changeaddr -oldaddr 127.0.0.1 -remove
-localauth -verbose
Could not remove server 127.0.0.1 from the VLDB
VLDB: volume Id exists in the vldb
    

I'd say to try and get a good vos dump of each volume that you care 
about so that you can at least restore to a new cell if things go bad 
from here.

Usually I'd fix this finding the volume that is listed as being on that 
IP and moving it to another server :-)  But it would seem that you have 
already done that.  I guess its possible that the vldb still thinks that 
127.0.0.1 is one of the servers somehow.  Did you try restarting your 
file servers?

Does vos syncvldb/syncserv do anything useful for you?  If not, it 
should be safe to shutdown the AFS server and delete the VL db files and 
have them get recreated at server startup.  (Might need to delete the 
sysid file as well.)

Or, vos dumping, deleting, and recreate each volume via vos restore may 
fix it, assuming you have fixed all 127.0.0.1 problems.

  
How would I go about resolving this?  By the way, thanks very much
for all of your help so far; you've really saved my ass on this.
    

No problem.  I'm glad it helped.

<<CDC 


_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
From shadow@gmail.com Fri Oct 5 15:12:10 2007 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 5 Oct 2007 10:12:10 -0400 Subject: [OpenAFS] gcc-4.2.1, afs-client not working In-Reply-To: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> References: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> Message-ID: ------=_Part_13881_4466294.1191593530021 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline If you can tell us which file or files when compiled with 4.2.1 are screwin= g up, it would make it easier to be able to figure out what's going on. On 10/5/07, Hans-Werner Paulsen wrote: > > Hello, > on i386_linux26 I compiled the kernel 2.6.22.9 and OpenAFS 1.4.4 > using the gcc 4.2.1. > Now I get: > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > # ls -l /afs > ls: cannot access /afs/mpa-garching.mpg.de: No such file or directory > ls: cannot access /afs/ipp-garching.mpg.de: No such file or directory > ls: cannot access /afs/world: No such file or directory > ls: cannot access /afs/rzg.mpg.de: No such file or directory > ls: cannot access /afs/andrew.cmu.edu: No such file or directory > total 14 > d????????? ? ? ? ? ? andrew.cmu.edu > drwxr-xr-x 11 root root 6144 Sep 21 07:18 ipp > ?????????? ? ? ? ? ? ipp-garching.mpg.de > drwxr-xr-x 3 root root 2048 Mar 30 2007 mpa > ?????????? ? ? ? ? ? mpa-garching.mpg.de > drwxr-xr-x 11 root root 6144 Sep 21 07:18 rzg > d????????? ? ? ? ? ? rzg.mpg.de > ?????????? ? ? ? ? ? world > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > When I recompiled the OpenAFS software using gcc 4.1.2 everything is fine= . > > Any idea or help? > > Hans-Werner > > -- > Hans-Werner Paulsen hans@MPA-Garching.MPG.DE > MPI f=FCr Astrophysik Tel 089-30000-2602 > Karl-Schwarzschild-Str. 1 Fax 089-30000-2235 > D-85741 Garching > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > ------=_Part_13881_4466294.1191593530021 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline If you can tell us which file or files when compiled with 4.2.1 are screwin= g up, it would make it easier to be able to figure out what's going on.=

On 10/5/07, Hans-Werner Paulsen <han= s@mpa-garching.mpg.de> wrote:
Hello,
on i386_linux26 I compiled the kernel 2.6.22.9 and OpenAFS 1.4.4
using the gcc 4.2.1.
Now I get:
= =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
# ls -l /afs
ls: cannot access /afs/mpa-garching.mpg.de: No such file or directory
ls: cannot access = /afs/ipp-garching.mpg.de: No such fi= le or directory
ls: cannot access /afs/world: No such file or directory
ls: cannot a= ccess /afs/rzg.mpg.de: No such file or directory
ls: cannot access /afs/= andrew.cmu.edu: No such file or directory
total 14
d????????? &n= bsp;? ?    ?       ? = ;           ?=20 andrew.cmu.edu
drwxr-xr-x 11 root = root 6144 Sep 21 07:18 ipp
??????????  ? ?   &n= bsp;?       ?     &n= bsp;      ? ipp-garching.mpg.de
drwxr-xr-x  3 root root 2048 Mar= 30  2007 mpa
??????????  ? ?    ?   &nb= sp;   ?         &nbs= p;  ? mpa-garching.mpg.de<= /a>
drwxr-xr-x 11 root root 6144 Sep 21 07:18 rzg
d????????? &nb= sp;? ?    ?       ? =            ? rzg.mpg.de
??????????  ? ?    ? &= nbsp;     ?       &n= bsp;    ? world
=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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

When I recompile= d the OpenAFS software using gcc 4.1.2 everything is fine.

Any idea or help?

Hans-Werner

--
Hans-Werner Pauls= en             = hans@MPA-Garching.MPG.DEMPI f=FCr Astrophysik         = ;    Tel 089-30000-2602
Karl-Schwarzschild-Str. 1 &n= bsp;     Fax 089-30000-2235
D-85741 Garching
_______________________________________________
= OpenAFS-info mailing list
Op= enAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

------=_Part_13881_4466294.1191593530021-- From jason@rampaginggeek.com Fri Oct 5 18:22:08 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Fri, 05 Oct 2007 13:22:08 -0400 Subject: [OpenAFS] Explorer crashes on Windows when RO volume is removed Message-ID: <470672C0.2080506@rampaginggeek.com> Hi, I was troubleshooting an issue at work in which I had to remove all of the RO replicas of a volume. I crashed a Windows XP computer that had the RO folder open. I mean explorer just crashed. What is supposed to happen when the RO replicas disappear (vos removed) from under a client? Sincerely, Jason From jaltman@secure-endpoints.com Fri Oct 5 18:38:18 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 05 Oct 2007 13:38:18 -0400 Subject: [OpenAFS] Explorer crashes on Windows when RO volume is removed In-Reply-To: <470672C0.2080506@rampaginggeek.com> References: <470672C0.2080506@rampaginggeek.com> Message-ID: <4706768A.3040806@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms090307070302060600030603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jason Edgecombe wrote: > Hi, > > I was troubleshooting an issue at work in which I had to remove all of > the RO replicas of a volume. I crashed a Windows XP computer that had > the RO folder open. I mean explorer just crashed. What is supposed to > happen when the RO replicas disappear (vos removed) from under a client? > > Sincerely, > Jason When the callbacks are broken on the volume, the AFS client will notify the Explorer Shell that something changed. When the Explorer Shell attempts to re-read it will be told NOSUCHPATH. If Explorer crashed, its a bug in Windows. Send the crash report to them. I'm sure the Shell team will be interested. Jeffrey Altman --------------ms090307070302060600030603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMDUxNzM4MThaMCMGCSqGSIb3DQEJBDEWBBRJH87I szp0Aie8Y6ZpT5vUjyT40DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAlgP/Man8/UdD4U2KKa9y8FDf1gaSk0I89ncT3+pzr/mK5QXgbHF8 /zRTZh06JYlMwXKgLQdREUtfwQBNjVEkewNpLng+aB/mWPKXEK+4hvA3jSzb+CEupY3gDrFe RN24jhbAA8mRRAX7neg4Y7KRGuFd8HYTE8eJbd5iXBqvaxscbM7cCRr2iZWbuqcJ3cYkJfnM i8/oxr30b+ShTPrk00xmOrmz4O+KMWHaeIKVVjNE2jSoo6wNMCRDKg+Qc2NwhNJ+kic+BmJI 5MrXZbDvZABDn4UpbffWHFm3y/9gi+S+e92uvd+OP94F7b8k8kXxRU7UeecNDwds0usRYJ9w 9wAAAAAAAA== --------------ms090307070302060600030603-- From rmdyer@uncc.edu Fri Oct 5 18:45:00 2007 From: rmdyer@uncc.edu (Rodney M. Dyer) Date: Fri, 05 Oct 2007 13:45:00 -0400 Subject: [OpenAFS] Explorer crashes on Windows when RO volume is removed In-Reply-To: <4706768A.3040806@secure-endpoints.com> References: <470672C0.2080506@rampaginggeek.com> <4706768A.3040806@secure-endpoints.com> Message-ID: <6.1.2.0.1.20071005134114.02fbcec0@unccmail.uncc.edu.> At 01:38 PM 10/5/2007, Jeffrey Altman wrote: >If Explorer crashed, its a bug in Windows. Send the crash report to >them. I'm sure the Shell team will be >interested. I'm not going to debug this problem. It is with the 1.4.202.0 client and I really don't care about it. We know that client has a plethora of bugs. The next client we are going to upgrade to will be the 1.5.xx version. Rodney From drosih@rpi.edu Fri Oct 5 19:26:38 2007 From: drosih@rpi.edu (Garance A Drosihn) Date: Fri, 5 Oct 2007 14:26:38 -0400 Subject: [OpenAFS] gcc-4.2.1, afs-client not working In-Reply-To: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> References: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> Message-ID: At 3:46 PM +0200 10/5/07, Hans-Werner Paulsen wrote: >Hello, >on i386_linux26 I compiled the kernel 2.6.22.9 and OpenAFS 1.4.4 >using the gcc 4.2.1. >Now I get: > [...problems...] > >When I recompiled the OpenAFS software using gcc 4.1.2 everything >is fine. > >Any idea or help? See what happens if you add: -fno-tree-vrp to the flags used for compiling openafs. This is just a guess on my part, but we have seen problems with -ftree-vrp in gcc 4.2.1 on FreeBSD-current. And that option is turned on if -O2 is specified. So, I guess you should also make sure that -fno-tree-vrp would be specified after -O2. Disclaimer: this is just a guess on my part. It gives you something to try, if you have some spare time. I reserve the right to be completely wrong! :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From phanee@gmail.com Fri Oct 5 21:39:25 2007 From: phanee@gmail.com (phanee) Date: Fri, 5 Oct 2007 13:39:25 -0700 (PDT) Subject: [OpenAFS] Solaris 10 does not resolve the @sys variable Message-ID: <13028027.post@talk.nabble.com> I have a /pkg as my mounting on afs which should resolve the @sys variable. So when I say cd /pkg it should go to /afs/gv/GV2/sun4x_510/... since the @sys variable is sun4x_510 in Solaris 10. Instead it gives /afs/gv/Gv2/@sys. When I open a software it complains that this directory does not exist and so I am not able to launch and use the software in Solaris 10. Therefore, is there a fix to it? Any help is appreciated Thanks Phaneendra -- View this message in context: http://www.nabble.com/Solaris-10-does-not-resolve-the-%40sys-variable-tf4564408.html#a13028027 Sent from the OpenAFS - General mailing list archive at Nabble.com. From deengert@anl.gov Fri Oct 5 21:56:30 2007 From: deengert@anl.gov (Douglas E. Engert) Date: Fri, 05 Oct 2007 15:56:30 -0500 Subject: [OpenAFS] Solaris 10 does not resolve the @sys variable In-Reply-To: <13028027.post@talk.nabble.com> References: <13028027.post@talk.nabble.com> Message-ID: <4706A4FE.5090904@anl.gov> phanee wrote: > I have a /pkg as my mounting on afs which should resolve the @sys variable. What do you mean by "as my mounting" Is it a symlink for /pkg->/afs/gv/GV2/@sys ? Could you use /afs/gv/GV2/sun4x_510 as you know what type system you are on. Or are you trying to use the AFS/NFS translator? > So when I say cd /pkg it should go to /afs/gv/GV2/sun4x_510/... since the > @sys variable is sun4x_510 in Solaris 10. Instead it gives /afs/gv/Gv2/@sys. > When I open a software it complains that this directory does not exist and > so I am not able to launch and use the software in Solaris 10. > > Therefore, is there a fix to it? Any help is appreciated What does fs sysname show? It should show Current sysname is 'sun4x_510' @sys works for us in sun4x_510. > Thanks > Phaneendra > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From norbert.schuch@googlemail.com Sat Oct 6 21:46:11 2007 From: norbert.schuch@googlemail.com (Norbert Schuch) Date: Sat, 6 Oct 2007 13:46:11 -0700 (PDT) Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <200708121157.02874.dirk.heinrichs@online.de> References: <200708121157.02874.dirk.heinrichs@online.de> Message-ID: <13077327.post@talk.nabble.com> Hi, Dirk Heinrichs-2 wrote: > > I'm currently facing strange behaviour on one client machine, which looks > like: > > [...] > heini@gondolin ~ % LANG="" ll /afs/altum.de > ls: cannot access /afs/altum.de/music: No such file or directory > I had the same problem after compiling a new kernel. However, I have discovered meanwhile that it is caused by the gcc version used: The 2.6.21.1 to 2.6.21.7 kernels all do NOT work with openafs-1.4.4 when compiled with gcc-4.2 (although both compile, and the driver is loaded -- only the afs cannot be accessed), whereas they work if compiled with gcc-4.0. Regards, Norbert -- View this message in context: http://www.nabble.com/Strange-access-problems-on-one-client-tf4256181.html#a13077327 Sent from the OpenAFS - General mailing list archive at Nabble.com. From openafs-info@openafs.org Sun Oct 7 11:50:32 2007 From: openafs-info@openafs.org (Axel Thimm) Date: Sun, 7 Oct 2007 13:50:32 +0300 Subject: [OpenAFS] Re: rpmbuild In-Reply-To: References: <470107F4.4020409@nd.edu> Message-ID: <20071007105032.GA21661@puariko.nirvana> --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 01, 2007 at 03:52:24PM +0100, Simon Wilkinson wrote: >=20 > On 1 Oct 2007, at 15:45, Peter Metcalf wrote: >=20 > >I have over the past several updates to the kernel failed at =20 > >building a new module for AFS. > >Using: rpmbuild --rebuild --target=3Di686 openafs.src.rpm > >My error I get: > >error: line 1: Unknown tag: %kmdl openafs > >Any help with this one? Try yum install atrpms-rpm-config kernel-devel before rpmbuild (BTW why rebuild? Security concerns, custom kernels or maybe some changes that more users might benefit from? The latter are always welcomed in patch form :) > You're using the ATRPMs packages, and not the OpenAFS ones. Actually it's the ATrpms packages for OpenAFS. :) > Trying asking on their mailing lists. > (I think you need an additional RPM macro set installed in order to =20 > rebuild atrpms packages - I'm not sure how (or if) this is distributed.) See above. For such a specific packaging question the ATrpms' lists would had been more suitable indeed, but in general most openafs/rpm questions turn out to be openafs proper topics, so people using openafs through rpms (or debs etc.) should not feel discouraged to ask questions here. --=20 Axel.Thimm at ATrpms.net --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHCLn4QBVS1GOamfERAuUmAKCTBhrZSlN64UnX27D7S5wWsTK/xACgmwGN Y+2vojA+QuFZ7y6WQ3CbHtU= =nTNc -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From marc.dionne@technoconseil.com Sun Oct 7 18:15:00 2007 From: marc.dionne@technoconseil.com (Marc Dionne) Date: Sun, 07 Oct 2007 13:15:00 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <13077327.post@talk.nabble.com> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> Message-ID: <47091414.4090800@technoconseil.com> This is a multi-part message in MIME format. --Boundary_(ID_V5syCXgy8SDDgedaatULpw) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Norbert Schuch wrote: > Hi, > > > Dirk Heinrichs-2 wrote: >> I'm currently facing strange behaviour on one client machine, which looks >> like: >> >> [...] >> heini@gondolin ~ % LANG="" ll /afs/altum.de >> ls: cannot access /afs/altum.de/music: No such file or directory >> > > I had the same problem after compiling a new kernel. However, > I have discovered meanwhile that it is caused by the > gcc version used: The 2.6.21.1 to 2.6.21.7 kernels all do NOT > work with openafs-1.4.4 when compiled with gcc-4.2 (although > both compile, and the driver is loaded -- only the afs cannot be > accessed), whereas they work if compiled with gcc-4.0. > > > Regards, > Norbert Anyone care to test out the attached patch for src/dir/dir.c The hashing code in the DirHash() function relies on integer overflow to make the hval value turn into a negative value. gcc 4.2 assumes that this value can never go negative and optimizes out the (hval < 0) test. Marc --Boundary_(ID_V5syCXgy8SDDgedaatULpw) Content-type: text/plain; CHARSET=US-ASCII; name=gcc_patch Content-transfer-encoding: 7BIT Content-disposition: inline; filename=gcc_patch Index: src/dir/dir.c =================================================================== RCS file: /cvs/openafs/src/dir/dir.c,v retrieving revision 1.24 diff -u -r1.24 dir.c --- src/dir/dir.c 13 Oct 2005 15:12:12 -0000 1.24 +++ src/dir/dir.c 7 Oct 2007 17:10:37 -0000 @@ -478,8 +478,9 @@ { /* Hash a string to a number between 0 and NHASHENT. */ register unsigned char tc; - register int hval; + unsigned long hval; register int tval; + hval = 0; while ((tc = (*string++))) { hval *= 173; @@ -488,7 +489,7 @@ tval = hval & (NHASHENT - 1); if (tval == 0) return tval; - else if (hval < 0) + else if (hval >= 1<<31) tval = NHASHENT - tval; return tval; } --Boundary_(ID_V5syCXgy8SDDgedaatULpw)-- From shadow@gmail.com Sun Oct 7 20:44:52 2007 From: shadow@gmail.com (Derrick Brashear) Date: Sun, 7 Oct 2007 15:44:52 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <47091414.4090800@technoconseil.com> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> Message-ID: ------=_Part_17029_23985266.1191786292767 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Omari Stephens confirmed this fixed a test system, and regardless it's harmless, so we'll run with this. Thanks! On 10/7/07, Marc Dionne wrote: > > Norbert Schuch wrote: > > Hi, > > > > > > Dirk Heinrichs-2 wrote: > >> I'm currently facing strange behaviour on one client machine, which > looks > >> like: > >> > >> [...] > >> heini@gondolin ~ % LANG="" ll /afs/altum.de > >> ls: cannot access /afs/altum.de/music: No such file or directory > >> > > > > I had the same problem after compiling a new kernel. However, > > I have discovered meanwhile that it is caused by the > > gcc version used: The 2.6.21.1 to 2.6.21.7 kernels all do NOT > > work with openafs-1.4.4 when compiled with gcc-4.2 (although > > both compile, and the driver is loaded -- only the afs cannot be > > accessed), whereas they work if compiled with gcc-4.0. > > > > > > Regards, > > Norbert > > Anyone care to test out the attached patch for src/dir/dir.c > > The hashing code in the DirHash() function relies on integer overflow to > make the hval value turn into a negative value. gcc 4.2 assumes that > this value can never go negative and optimizes out the (hval < 0) test. > > Marc > > > Index: src/dir/dir.c > =================================================================== > RCS file: /cvs/openafs/src/dir/dir.c,v > retrieving revision 1.24 > diff -u -r1.24 dir.c > --- src/dir/dir.c 13 Oct 2005 15:12:12 -0000 1.24 > +++ src/dir/dir.c 7 Oct 2007 17:10:37 -0000 > @@ -478,8 +478,9 @@ > { > /* Hash a string to a number between 0 and NHASHENT. */ > register unsigned char tc; > - register int hval; > + unsigned long hval; > register int tval; > + > hval = 0; > while ((tc = (*string++))) { > hval *= 173; > @@ -488,7 +489,7 @@ > tval = hval & (NHASHENT - 1); > if (tval == 0) > return tval; > - else if (hval < 0) > + else if (hval >= 1<<31) > tval = NHASHENT - tval; > return tval; > } > > ------=_Part_17029_23985266.1191786292767 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Omari Stephens confirmed this fixed a test system, and regardless it's harmless, so we'll run with this.

Thanks!


On 10/7/07, Marc Dionne <marc.dionne@technoconseil.com> wrote:
Norbert Schuch wrote:
> Hi,
>
>
> Dirk Heinrichs-2 wrote:
>> I'm currently facing strange behaviour on one client machine, which looks
>> like:
>>
>> [...]
>> heini@gondolin ~ % LANG="" ll /afs/altum.de
>> ls: cannot access /afs/altum.de/music: No such file or directory
>>
>
> I had the same problem after compiling a new kernel. However,
> I have discovered meanwhile that it is caused by the
> gcc version used: The 2.6.21.1 to 2.6.21.7 kernels all do NOT
> work with openafs-1.4.4 when compiled with gcc-4.2 (although
> both compile, and the driver is loaded -- only the afs cannot be
> accessed), whereas they work if compiled with gcc-4.0.
>
>
> Regards,
> Norbert

Anyone care to test out the attached patch for src/dir/dir.c

The hashing code in the DirHash() function relies on integer overflow to
make the hval value turn into a negative value.  gcc 4.2 assumes that
this value can never go negative and optimizes out the (hval < 0) test.

Marc


Index: src/dir/dir.c
===================================================================
RCS file: /cvs/openafs/src/dir/dir.c,v
retrieving revision 1.24
diff -u -r1.24 dir.c
--- src/dir/dir.c       13 Oct 2005 15:12:12 -0000      1.24
+++ src/dir/dir.c       7 Oct 2007 17:10:37 -0000
@@ -478,8 +478,9 @@
{
     /* Hash a string to a number between 0 and NHASHENT. */
     register unsigned char tc;
-    register int hval;
+    unsigned long hval;
     register int tval;
+
     hval = 0;
     while ((tc = (*string++))) {
        hval *= 173;
@@ -488,7 +489,7 @@
     tval = hval & (NHASHENT - 1);
     if (tval == 0)
        return tval;
-    else if (hval < 0)
+    else if (hval >= 1<<31)
        tval = NHASHENT - tval;
     return tval;
}


------=_Part_17029_23985266.1191786292767-- From dirk.heinrichs.ext@nsn.com Mon Oct 8 07:11:50 2007 From: dirk.heinrichs.ext@nsn.com (Dirk Heinrichs) Date: Mon, 8 Oct 2007 08:11:50 +0200 Subject: [OpenAFS] gcc-4.2.1, afs-client not working In-Reply-To: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> References: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> Message-ID: <200710080811.55621.dirk.heinrichs.ext@nsn.com> --nextPart3662408.EMzaU4Nnzl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 5. Oktober 2007 schrieb ext Hans-Werner Paulsen: > Hello, > on i386_linux26 I compiled the kernel 2.6.22.9 and OpenAFS 1.4.4 > using the gcc 4.2.1. > Now I get: > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D=3D # ls -l /afs > ls: cannot access /afs/mpa-garching.mpg.de: No such file or directory > ls: cannot access /afs/ipp-garching.mpg.de: No such file or directory > ls: cannot access /afs/world: No such file or directory > ls: cannot access /afs/rzg.mpg.de: No such file or directory > ls: cannot access /afs/andrew.cmu.edu: No such file or directory > total 14 > d????????? ? ? ? ? ? andrew.cmu.edu > drwxr-xr-x 11 root root 6144 Sep 21 07:18 ipp > ?????????? ? ? ? ? ? ipp-garching.mpg.de > drwxr-xr-x 3 root root 2048 Mar 30 2007 mpa > ?????????? ? ? ? ? ? mpa-garching.mpg.de > drwxr-xr-x 11 root root 6144 Sep 21 07:18 rzg > d????????? ? ? ? ? ? rzg.mpg.de > ?????????? ? ? ? ? ? world > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D=3D > > When I recompiled the OpenAFS software using gcc 4.1.2 everything is > fine. Looks like the reason for the problem I had. See thread "Strange access=20 problems on one client". Bye... Dirk =2D-=20 Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: dirk.heinrichs@capgemini.com Wanheimerstra=DFe 68 | Web: http://www.capgemini.com D-40468 D=FCsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net --nextPart3662408.EMzaU4Nnzl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQBHCcor8NVtnsLkZ7sRAlQBAKCW4BLrdtFibVa6lGFsUfiZsKpmVgCfaRnK xf4cbMmdydJr/yoR+IJI98U= =yH8e -----END PGP SIGNATURE----- --nextPart3662408.EMzaU4Nnzl-- From dirk.heinrichs.ext@nsn.com Mon Oct 8 07:12:59 2007 From: dirk.heinrichs.ext@nsn.com (Dirk Heinrichs) Date: Mon, 8 Oct 2007 08:12:59 +0200 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: References: <200708121157.02874.dirk.heinrichs@online.de> <47091414.4090800@technoconseil.com> Message-ID: <200710080813.00078.dirk.heinrichs.ext@nsn.com> --nextPart108354141.Klz6Y1DOfd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 7. Oktober 2007 schrieb ext Derrick Brashear: > Omari Stephens confirmed this fixed a test system, and regardless it's > harmless, so we'll run with this. I'm glad to see the issue could be resolved. Bye... Dirk =2D-=20 Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: dirk.heinrichs@capgemini.com Wanheimerstra=C3=9Fe 68 | Web: http://www.capgemini.com D-40468 D=C3=BCsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net --nextPart108354141.Klz6Y1DOfd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQBHCcps8NVtnsLkZ7sRAqawAJ9f4tH306N+TVndmLbr6kWtOARO6wCfRyqf hbYjvJMHOxcyDY8eDZEUAlU= =IeaL -----END PGP SIGNATURE----- --nextPart108354141.Klz6Y1DOfd-- From thomas.mueller@hrz.tu-chemnitz.de Mon Oct 8 11:04:48 2007 From: thomas.mueller@hrz.tu-chemnitz.de (Thomas Mueller) Date: Mon, 8 Oct 2007 12:04:48 +0200 (MEST) Subject: [OpenAFS] OpenAFS for Windows vs German Vista In-Reply-To: <47044E20.20204@secure-endpoints.com> References: <47044E20.20204@secure-endpoints.com> Message-ID: On Wed, 3 Oct 2007, Jeffrey Altman wrote: > If you have successfully or unsuccessfully installed OpenAFS for Windows > 1.5.25 on German Windows. Please let me know. We've installed 1.5.25 on one system with German Windows Vista some days ago. No Problems so far. Thank you, Thomas. From jaltman@secure-endpoints.com Mon Oct 8 12:12:54 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 08 Oct 2007 07:12:54 -0400 Subject: [OpenAFS] OpenAFS for Windows vs German Vista In-Reply-To: References: <47044E20.20204@secure-endpoints.com> Message-ID: <470A10B6.6070706@secure-endpoints.com> Thomas Mueller wrote: > On Wed, 3 Oct 2007, Jeffrey Altman wrote: > >> If you have successfully or unsuccessfully installed OpenAFS for Windows >> 1.5.25 on German Windows. Please let me know. > > We've installed 1.5.25 on one system with German Windows Vista some days > ago. No Problems so far. Thank you. I asked because there were several Windows Error Reports that were received from German Vista systems. However, I believe the problem is not generic to non-English Vista systems. 1.5.25 has a bug that will result in a crash when a file is renamed only by case. Such as "FOO" to "foo". This has been fixed and will be included in next weeks 1.5.26 release. Jeffrey Altman From dhk@ccre.com Mon Oct 8 14:38:33 2007 From: dhk@ccre.com (Kim Kimball) Date: Mon, 08 Oct 2007 07:38:33 -0600 Subject: *** Spam *** Re: [OpenAFS] AFS Fileserver Won't Start --> Can't Release root.cell or root.afs In-Reply-To: <4593279.1191592875751.JavaMail.root@m11> References: <008001c8062f$e8fb44f0$baf1ced0$@com> <0FC21FD9E7D240F882DB8D228835DC69@CDCHOME> <000301c80656$92613f60$b723be20$@com> <20254.194.237.142.10.1191483718.squirrel@webmail.sys.kth.se> <000501c8065d$a2ae8290$e80b87b0$@com> <000001c80671$002a9180$007fb480$@com> <00DF219235DC4AB8B1A352026A33D8EC@CDCHOME> <00bf01c806e4$c11ecaf0$435c60d0$@com> <31840886.1191560299507.JavaMail.root@m11> <470636FB.40706@ccre.com> <4593279.1191592875751.JavaMail.root@m11> Message-ID: <470A32D9.9010804@ccre.com> 
How does one know that the 127.* IPs really are gone?
vos listaddr

>From a client-only machine, 'vos listvl -server 127.0.0.1'

Kim


Christopher D. Clausen wrote: 
Kim Kimball <dhk@ccre.com> wrote:
  
You might also try
vos remove <server> <partition> <volumename>.readonly     #for each
readonly instance
vos backup <volumename>
vos dump <volumename>.backup | vos restore <server> <partition>
<volumename> -overwrite full

Use the same volume name for each instance of <volumename>

This will give you a new volumeID for <volumename> which will be
reflected in the VLDB. Then "vos addsite" to replace the RO sites.
Then "vos release"
    

I was going to suggest that, but I figured it may not actually clear up 
the problem and could potentially just waste a lot of time.

How does one know that the 127.* IPs really are gone?

-----

When specifing server names, DO NOT use "localhost" or "127.0.0.1."  Use 
the FQDNs of your servers.

-----

Hmm... would vos delent for each volume, then the vos 
changeaddr -remove, and then a vos syncvldb do the same thing and not 
take as much time for the dump / restores?

<<CDC 


_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
From jan.kaspar@gmail.com Tue Oct 9 11:04:33 2007 From: jan.kaspar@gmail.com (Jan Kaspar) Date: Tue, 9 Oct 2007 12:04:33 +0200 Subject: [OpenAFS] problems with OpenAFS 1.4.4 on Linux Message-ID: SGVsbG8sCgpJJ3ZlIGJlZW4gc3RydWdnbGluZyB3aXRoIEFGUyBjb25maWd1cmF0aW9uIGF0IG91 ciBpbnN0aXR1dGUgZm9yIGEKbG9uZyB0aW1lLiBBbmQgc28gZmFyIHVuc3VjY2Vzc2Z1bGx5LiBJ IGhvcGUgc29tZSBvZiB5b3UgZ3V5cyBjb3VsZApoZWxwIG1lLiBJJ2QgcmVhbGx5IGFwcHJlY2lh dGUgaXQuCgpUaGUgcHJvYmxlbSBpcyB0aGUgZm9sbG93aW5nLiBBZnRlciBzdGFydGluZyB1cCBh ZnNkLCBsb2dpbiBvbiBteQpsb2NhbCBtYWNoaW5lIGFuZCBvYnRhaW5pbmcgYW4gQUZTIHRpY2tl dCwgSSBjYW4gc2VlIGp1c3Qgc29tZSBvZgpmaWxlcyBhdCBBRlM6Cgp+PiB0b2tlbnMKClRva2Vu cyBoZWxkIGJ5IHRoZSBDYWNoZSBNYW5hZ2VyOgoKVXNlcidzIChBRlMgSUQgMjE3NykgdG9rZW5z IGZvciBhZnNAY2Vybi5jaCBbRXhwaXJlcyBPY3QgMTAgMTM6MTZdCiAgIC0tRW5kIG9mIGxpc3Qt LQoKfj4ga2xpc3QKQ3JlZGVudGlhbHMgY2FjaGU6IEZJTEU6L3RtcC9rcmI1Y2NfMjE3NwogICAg ICAgIFByaW5jaXBhbDogamthc3BhckBDRVJOLkNICgogIElzc3VlZCAgICAgICAgICAgRXhwaXJl cyAgICAgICAgICBQcmluY2lwYWwKT2N0ICA5IDExOjUwOjA5ICBPY3QgMTAgMTI6NTA6MDkgIGty YnRndC9DRVJOLkNIQENFUk4uQ0gKT2N0ICA5IDExOjUwOjA5ICBPY3QgMTAgMTI6NTA6MDkgIGFm c0BDRVJOLkNICgovYWZzL2Nlcm4uY2gvdXNlci9qL2prYXNwYXI+IGxzIC1sCmxzOiBjYW5ub3Qg YWNjZXNzIHB1YmxpYzogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQpsczogY2Fubm90IGFjY2Vz cyBwcml2YXRlOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5CmxzOiBjYW5ub3QgYWNjZXNzIGJh Y2tncm91bmQucHM6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKdG90YWwgMTMKZHJ3eHIteHIt eCAyIGprYXNwYXIgemogMjA0OCAyMDA3LTA1LTEwIDE1OjQyIERlc2t0b3AKLT8/Pz8/Pz8/PyA/ ID8gICAgICAgPyAgICAgPyAgICAgICAgICAgICAgICA/IGJhY2tncm91bmQucHMKZHJ3eHIteHIt eCAyIGprYXNwYXIgemogMjA0OCAyMDA3LTA1LTEwIDE2OjA4IGJpbgpkcnd4LS0tLS0tIDIgamth c3BhciB6aiAyMDQ4IDIwMDYtMTEtMjEgMjE6NTEgbWFpbApkcnd4ci14ci14IDUgamthc3BhciB6 aiAyMDQ4IDIwMDctMDYtMjIgMTk6Mzcgb2xkX3d3dwpkPz8/Pz8/Pz8/ID8gPyAgICAgICA/ICAg ICA/ICAgICAgICAgICAgICAgID8gcHJpdmF0ZQpkPz8/Pz8/Pz8/ID8gPyAgICAgICA/ICAgICA/ ICAgICAgICAgICAgICAgID8gcHVibGljCi4uLgoKSXQgaXMgcmVhbGx5IHdlaXJkLiBUaGUgZmls ZSBiYWNrZ3JvdW5kLnBzIHdhcyBjb3BpZWQgdG8gQUZTIGJ5IG1lCmZyb20gbXkgbG9jYWwgbWFj aGluZS4gRGlyZWN0bHkgYWZ0ZXIgdGhlIGNvcHksIEkgY291bGQgbGlzdCBhbmQgZXZlbgplZGl0 IHRoZSBmaWxlLiBUaGVuLCBvbiBhIGRpZmZlcmVudCBtYWNoaW5lIGEgcGxheWVkIGEgYml0IHdp dGggbXkgQUZTCmZpbGVzIChqdXN0IG1vdmUgcHVibGljIGRpcmVjdG9yeSBjb250ZW50cyB0aGVy ZSBhbmQgYmFjaykuIEFuZCBhZnRlcgp0aGF0LCBscyBydW4gb24gbXkgbWFjaGluZSBnaXZlcyBi YWNrZ3JvdW5kLnBzIHdpdGggdGhvc2UgPz8/Pz8KCkkgZG8gbm90IGtub3cgd2hldGhlciB0aGlz IGlzIGEgbWlzY29uZmlndXJhdGlvbiBwcm9ibGVtIG9yIGEgYnVnLiBIYXMKc29tZW9uZSBleHBl cmllbmNlZCBiZWhhdmlvciBsaWtlIHRoaXM/CgpJcyB0aGVyZSBhIHdheSBob3cgdG8gZHVidWcg QUZTPyBJIHRyaWVkIHRvIHBhc3MgLWxvZ2ZpbGUgYXJndW1lbnQgdG8KYWZzZCwgYnV0IEkgd2Fz IHRvbGQgaXQgaXMgYW4gb2Jzb2xldGUgb3B0aW9uIHdpdGggbm8gZWZmZWN0Li4uCgpJIHJ1biBB RlMgZGFlbW9uIGFzCiAgICAvdXNyL2Jpbi9hZnNkIC1kYWVtb25zIDIgLWRjYWNoZSAxMDAgLXN0 YXQgMzAwIC12b2x1bWVzIDUwCih0aGUgcGFyYW1ldGVycyBhcmUgdmVyeSBzaW1pbGFyIHRvIHRo b3NlIHdoaWNoIGFyZSB1c2VkIGF0IHB1YmxpYwptYWNoaW5lcyBhdCBteSBpbnN0aXR1dGUpLiBO b3cgSSdtIHJ1bm5pbmcgd2l0aCBleHQzIGNhY2hlLCBidXQgYmVmb3JlCkkgdHJpZWQgYWxzbyBl eHQyLiBBbmQgc3RpbGwgdGhlIHNhbWUuIEkgc3VzcGVjdCAoYnV0IEkgZG9uJ3QgcmVhbGx5Cmtu b3cgaG93IHRvIHZlcmlmeSkgdGhlIEFGUyBzZXJ2ZXJzIHRvIHJ1biBhbiBvbGRlciB2ZXJzaW9u IG9mIEFGUwp0aGFuIDEuNC40LiBNYXkgdGhhdCBiZSBvZiBpbXBvcnRhbmNlPwoKVGhhbmsgeW91 IHZlcnkgbXVjaCBmb3IgYW55IGhpbnQuCgpDaGVlcnMsIEphbiBLYcWhcGFyLgo= From hans@MPA-Garching.MPG.DE Tue Oct 9 11:23:44 2007 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Tue, 9 Oct 2007 12:23:44 +0200 Subject: [OpenAFS] gcc-4.2.1, afs-client not working In-Reply-To: References: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> Message-ID: <20071009102344.GA1426@ncq-5.MPA-Garching.MPG.DE> On Fri, Oct 05, 2007 at 10:12:10AM -0400, Derrick Brashear wrote: > If you can tell us which file or files when compiled with 4.2.1 are scr= ewing > up, it would make it easier to be able to figure out what's going on. Of course, but I did not understand how the different Makefiles work to compile the kernel module, and how to specify different compiler flags for different source files. Now I have some results: Garance A Drosihn suggested to try the gcc option -fno-tree-vrp, and yes the kernel module compiled with this option runs fine. In addition only the source file src/libafs/MODLOAD-2.6.22.9-MP/afs_dir.c= , which is src/dir/dir.c, needs to be compiled with this option. HW --=20 Hans-Werner Paulsen hans@MPA-Garching.MPG.DE MPI f=FCr Astrophysik Tel 089-30000-2602 Karl-Schwarzschild-Str. 1 Fax 089-30000-2235=09 D-85741 Garching From norbert.schuch@googlemail.com Tue Oct 9 12:11:15 2007 From: norbert.schuch@googlemail.com (Norbert Schuch) Date: Tue, 9 Oct 2007 13:11:15 +0200 Subject: [OpenAFS] problems with OpenAFS 1.4.4 on Linux In-Reply-To: References: Message-ID: <92e441a90710090411wc846036ue464156375ecb546@mail.gmail.com> Hi, this seems the same problem as in http://www.nabble.com/Strange-access-problems-on-one-client-tf4256181.html#= a13077327 Basically, this is a problem with between openafs and gcc-4.2. So either use an older gcc, or use the patch found later in this thread. Norbert On 10/9/07, Jan Kaspar wrote: > Hello, > > I've been struggling with AFS configuration at our institute for a > long time. And so far unsuccessfully. I hope some of you guys could > help me. I'd really appreciate it. > > The problem is the following. After starting up afsd, login on my > local machine and obtaining an AFS ticket, I can see just some of > files at AFS: > > ~> tokens > > Tokens held by the Cache Manager: > > User's (AFS ID 2177) tokens for afs@cern.ch [Expires Oct 10 13:16] > --End of list-- > > ~> klist > Credentials cache: FILE:/tmp/krb5cc_2177 > Principal: jkaspar@CERN.CH > > Issued Expires Principal > Oct 9 11:50:09 Oct 10 12:50:09 krbtgt/CERN.CH@CERN.CH > Oct 9 11:50:09 Oct 10 12:50:09 afs@CERN.CH > > /afs/cern.ch/user/j/jkaspar> ls -l > ls: cannot access public: No such file or directory > ls: cannot access private: No such file or directory > ls: cannot access background.ps: No such file or directory > total 13 > drwxr-xr-x 2 jkaspar zj 2048 2007-05-10 15:42 Desktop > -????????? ? ? ? ? ? background.ps > drwxr-xr-x 2 jkaspar zj 2048 2007-05-10 16:08 bin > drwx------ 2 jkaspar zj 2048 2006-11-21 21:51 mail > drwxr-xr-x 5 jkaspar zj 2048 2007-06-22 19:37 old_www > d????????? ? ? ? ? ? private > d????????? ? ? ? ? ? public > ... > > It is really weird. The file background.ps was copied to AFS by me > from my local machine. Directly after the copy, I could list and even > edit the file. Then, on a different machine a played a bit with my AFS > files (just move public directory contents there and back). And after > that, ls run on my machine gives background.ps with those ????? > > I do not know whether this is a misconfiguration problem or a bug. Has > someone experienced behavior like this? > > Is there a way how to dubug AFS? I tried to pass -logfile argument to > afsd, but I was told it is an obsolete option with no effect... > > I run AFS daemon as > /usr/bin/afsd -daemons 2 -dcache 100 -stat 300 -volumes 50 > (the parameters are very similar to those which are used at public > machines at my institute). Now I'm running with ext3 cache, but before > I tried also ext2. And still the same. I suspect (but I don't really > know how to verify) the AFS servers to run an older version of AFS > than 1.4.4. May that be of importance? > > Thank you very much for any hint. > > Cheers, Jan Ka=9Apar. > From hans@MPA-Garching.MPG.DE Tue Oct 9 12:40:19 2007 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Tue, 9 Oct 2007 13:40:19 +0200 Subject: [OpenAFS] gcc-4.2.1, afs-client not working In-Reply-To: <20071009102344.GA1426@ncq-5.MPA-Garching.MPG.DE> References: <20071005134648.GA8599@ncq-5.MPA-Garching.MPG.DE> <20071009102344.GA1426@ncq-5.MPA-Garching.MPG.DE> Message-ID: <20071009114019.GA3560@ncq-5.MPA-Garching.MPG.DE> On Tue, Oct 09, 2007 at 12:23:44PM +0200, Hans-Werner Paulsen wrote: > blabla... Sorry, this problem is "Strange access problems on one client" and alread= y solved. HW --=20 Hans-Werner Paulsen hans@MPA-Garching.MPG.DE MPI f=FCr Astrophysik Tel 089-30000-2602 Karl-Schwarzschild-Str. 1 Fax 089-30000-2235=09 D-85741 Garching From shadow@gmail.com Tue Oct 9 14:37:10 2007 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 9 Oct 2007 09:37:10 -0400 Subject: [OpenAFS] problems with OpenAFS 1.4.4 on Linux In-Reply-To: References: Message-ID: ------=_Part_2172_24815929.1191937030853 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What kernel version on those clients? ------=_Part_2172_24815929.1191937030853 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What kernel version on those clients?

------=_Part_2172_24815929.1191937030853-- From jan.kaspar@gmail.com Tue Oct 9 14:47:05 2007 From: jan.kaspar@gmail.com (Jan Kaspar) Date: Tue, 9 Oct 2007 15:47:05 +0200 Subject: [OpenAFS] problems with OpenAFS 1.4.4 on Linux In-Reply-To: References: Message-ID: VGhhbmsgeW91IGd1eXMgdmVyeSBtdWNoLiBUaGUgaXNzdWUgd2FzIGFscmVhZHkgc29sdmVkIGFm dGVyIHJlYWRpbmcKCmh0dHA6Ly93d3cubmFiYmxlLmNvbS9TdHJhbmdlLWFjY2Vzcy1wcm9ibGVt cy1vbi1vbmUtY2xpZW50LXRmNDI1NjE4MS5odG1sI2ExMzA3NzMyNwoKYW5kIGFwcGx5aW5nIHRo ZSBzdWdnZXN0IHBhdGNoLiBUaGFua3MgYWdhaW4sCgpjaGVlcnMsIEthxaFwaS4KCgoyMDA3LzEw LzksIERlcnJpY2sgQnJhc2hlYXIgPHNoYWRvd0BnbWFpbC5jb20+Ogo+IFdoYXQga2VybmVsIHZl cnNpb24gb24gdGhvc2UgY2xpZW50cz8KCi0tIApNeSB3ZWIgcGFnZTogaHR0cDovL2Nlcm4uY2gv amthc3Bhci8KTXkgY2VsbCBwaG9uZTogKzQxNzYgMjA2IDU5MzIK From norbert.schuch@googlemail.com Fri Oct 5 22:38:32 2007 From: norbert.schuch@googlemail.com (Norbert Schuch) Date: Fri, 5 Oct 2007 14:38:32 -0700 (PDT) Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <200708121157.02874.dirk.heinrichs@online.de> References: <200708121157.02874.dirk.heinrichs@online.de> Message-ID: <13067818.post@talk.nabble.com> Hi, I had the same problem -- No such file or directory errors -- after upgrading the 2.6.21 (self-compiled) kernel to the most recent Debian sources. After some experiments, I figured out that it probably depends on the gcc version. The new kernel has been compiled with gcc-4.2, and indeed no kernel in the 2.6.21 series works with openafs if compiled with gcc-4.2. If I however compile it with gcc-4.0, it works again with openafs. So trying a different gcc version might help. Regards, Norbert -- View this message in context: http://www.nabble.com/Strange-access-problems-on-one-client-tf4256181.html#a13067818 Sent from the OpenAFS - General mailing list archive at Nabble.com. From mansaxel@kthnoc.net Tue Oct 9 10:39:40 2007 From: mansaxel@kthnoc.net (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Tue, 09 Oct 2007 11:39:40 +0200 Subject: [OpenAFS] Re: [OpenAFS-devel] [REVIEW] Can haz Solaris 10 8/07 compatibility patch In-Reply-To: References: Message-ID: --==========F607EDF4D96756DEC9AB========== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On onsdag, onsdag 26 sep 2007 19.35.44 -0400 Dale Ghent wrote: >=20 > Here's a candidate patch for those of you running any version of Solaris > 10, or have hopes of running OpenAFS on Solaris 10 8/07 (update 4); Built on=20 paka.besserwisser.org$ uname -a SunOS paka.besserwisser.org 5.10 Generic_125100-10 sun4u sparc = SUNW,Ultra-80 ..using.. paka.besserwisser.org$ /opt/SUNWspro/bin/cc -V cc: Sun C 5.8 2005/10/13 usage: cc [ options] files. Use 'cc -flags' for details ...with the following invocation:=20 ./configure --with-krb5-conf=3D/usr/heimdal/bin/krb5-config \ --enable-transarc-paths \ --host=3Dsparc-sun-solaris2.10 Runs without problems on:=20 SunOS esgp.besserwisser.org 5.10 Generic_120011-14 sun4u sparc SUNW,UltraAX-i2 Solves my problem. Thanks a lot, Dale!=20 Blob for at-ones-own-risk consumption:=20 /afs/besserwisser.org/home/mansaxel/Public/sun4x_510-1.4.4.tar.gz --=20 M=C3=A5ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE Is this TERMINAL fun? --==========F607EDF4D96756DEC9AB========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFHC0xd02/pMZDM1cURAqteAKCHFKdHSJz0W0RuFRkv/w1PTylwKgCeMuNA Q8aDM3MnVra+JEk1H6PHMkA= =GC0W -----END PGP SIGNATURE----- --==========F607EDF4D96756DEC9AB==========-- From norbert.schuch@mpq.mpg.de Tue Oct 9 11:32:08 2007 From: norbert.schuch@mpq.mpg.de (Norbert Schuch) Date: Tue, 9 Oct 2007 12:32:08 +0200 Subject: [OpenAFS] problems with OpenAFS 1.4.4 on Linux In-Reply-To: References: Message-ID: <92e441a90710090332y2adf9d3aw9b5b09ef8947f1a6@mail.gmail.com> Hi, this seems the same problem as in http://www.nabble.com/Strange-access-problems-on-one-client-tf4256181.html#= a13077327 Basically, this is a problem with between openafs and gcc-4.2. So either use an older gcc, or use the patch found later in this thread. Norbert On 10/9/07, Jan Kaspar wrote: > Hello, > > I've been struggling with AFS configuration at our institute for a > long time. And so far unsuccessfully. I hope some of you guys could > help me. I'd really appreciate it. > > The problem is the following. After starting up afsd, login on my > local machine and obtaining an AFS ticket, I can see just some of > files at AFS: > > ~> tokens > > Tokens held by the Cache Manager: > > User's (AFS ID 2177) tokens for afs@cern.ch [Expires Oct 10 13:16] > --End of list-- > > ~> klist > Credentials cache: FILE:/tmp/krb5cc_2177 > Principal: jkaspar@CERN.CH > > Issued Expires Principal > Oct 9 11:50:09 Oct 10 12:50:09 krbtgt/CERN.CH@CERN.CH > Oct 9 11:50:09 Oct 10 12:50:09 afs@CERN.CH > > /afs/cern.ch/user/j/jkaspar> ls -l > ls: cannot access public: No such file or directory > ls: cannot access private: No such file or directory > ls: cannot access background.ps: No such file or directory > total 13 > drwxr-xr-x 2 jkaspar zj 2048 2007-05-10 15:42 Desktop > -????????? ? ? ? ? ? background.ps > drwxr-xr-x 2 jkaspar zj 2048 2007-05-10 16:08 bin > drwx------ 2 jkaspar zj 2048 2006-11-21 21:51 mail > drwxr-xr-x 5 jkaspar zj 2048 2007-06-22 19:37 old_www > d????????? ? ? ? ? ? private > d????????? ? ? ? ? ? public > ... > > It is really weird. The file background.ps was copied to AFS by me > from my local machine. Directly after the copy, I could list and even > edit the file. Then, on a different machine a played a bit with my AFS > files (just move public directory contents there and back). And after > that, ls run on my machine gives background.ps with those ????? > > I do not know whether this is a misconfiguration problem or a bug. Has > someone experienced behavior like this? > > Is there a way how to dubug AFS? I tried to pass -logfile argument to > afsd, but I was told it is an obsolete option with no effect... > > I run AFS daemon as > /usr/bin/afsd -daemons 2 -dcache 100 -stat 300 -volumes 50 > (the parameters are very similar to those which are used at public > machines at my institute). Now I'm running with ext3 cache, but before > I tried also ext2. And still the same. I suspect (but I don't really > know how to verify) the AFS servers to run an older version of AFS > than 1.4.4. May that be of importance? > > Thank you very much for any hint. > > Cheers, Jan Ka=9Apar. > From jaltman@secure-endpoints.com Tue Oct 9 20:55:59 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 09 Oct 2007 13:55:59 -0600 Subject: [OpenAFS] Re: Chronic blocked connections on fileserver In-Reply-To: <20070928154845.GD28023@lass.lfod.us> References: <20070924132346.GX19736@lass.lfod.us> <20070924132458.GY19736@lass.lfod.us> <20070924133536.GA22773@citi.umich.edu> <20070928154845.GD28023@lass.lfod.us> Message-ID: <470BDCCF.3060202@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080004050607070507040200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Will Maier wrote: > After 48 or so hours, the extended periods of badness returned. > These periods are still isolated to this one host and otherwise > resemble what we saw last week. Make sure that said host is not being a NAT or Firewall that is dropping the UDP port mappings in under 5 minutes. For best performance and to protect your file servers, UDP port mappings should be 10 minutes or higher. Jeffrey Altman --------------ms080004050607070507040200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMDkxOTU1NTlaMCMGCSqGSIb3DQEJBDEWBBSEWOoP bNINJFT3vJPfHiqIpjFr4TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAVSdYBV6x7r3LM6VN10S5DaKh2zeaqnQKGvpYAr19wt9DOkCgIYeh x2L907IqAGB5HDOZlo6tCeZ9WvNhARLLBywUfM4ophCCmGrKsHOrVXeTTP1sjwqFb70i7Z3S n4TgGAicw4kDJporN1y4+YtbpOntMpF2Moq2BpMG1PBPFZVmyodKGCkaYXU85AGi5L+aLAWO Tq+fQN23DGoQQlmn/4XqhXd3Om1UdMLB1NYqLZIgjpobMvejZGVxCXexOrus7943TlLo6sAN uc/Lk5IFH/nDuf/ZSpRcWsEFUPdgnvY+P0wj+eL/SGFWOdLHBtLSrR8EYhYRRnKkULkoV5fp lgAAAAAAAA== --------------ms080004050607070507040200-- From rees@umich.edu Tue Oct 9 21:07:06 2007 From: rees@umich.edu (Jim Rees) Date: Tue, 9 Oct 2007 16:07:06 -0400 Subject: [OpenAFS] Re: Chronic blocked connections on fileserver In-Reply-To: <20070928154845.GD28023@lass.lfod.us> References: <20070924132346.GX19736@lass.lfod.us> <20070924132458.GY19736@lass.lfod.us> <20070924133536.GA22773@citi.umich.edu> <20070928154845.GD28023@lass.lfod.us> Message-ID: <20071009200706.GA22604@citi.umich.edu> Will Maier wrote: On a whim, I thought I'd take a look at the hosts hitting us during a representative bad period. That's not as interesting as which hosts are blocking the file server. Some things to check for: file server is hung trying to talk to pts file server is hung trying to recall callbacks from unresponsive clients There may be clues in your FileLog. I'd be suspicious of 128.104.3.108 and 128.104.3.109. They are unreachable right now, at least from here. If they are doing thousands of Fetchstatuses but can't be reached by the file server for callbacks, that could foul things up. Is that subnet behind a firewall? Your message was delayed to the list by a couple of weeks. Is the 1.4.4 file server any better now than the 1.4.1? From willmaier@ml1.net Tue Oct 9 21:20:01 2007 From: willmaier@ml1.net (Will Maier) Date: Tue, 9 Oct 2007 15:20:01 -0500 Subject: [OpenAFS] Re: Chronic blocked connections on fileserver In-Reply-To: <20071009200706.GA22604@citi.umich.edu> References: <20070924132346.GX19736@lass.lfod.us> <20070924132458.GY19736@lass.lfod.us> <20070924133536.GA22773@citi.umich.edu> <20070928154845.GD28023@lass.lfod.us> <20071009200706.GA22604@citi.umich.edu> Message-ID: <20071009202001.GD14302@lass.lfod.us> On Tue, Oct 09, 2007 at 04:07:06PM -0400, Jim Rees wrote: > Will Maier wrote: > > On a whim, I thought I'd take a look at the hosts hitting us > > during a representative bad period. > > That's not as interesting as which hosts are blocking the file server. Some > things to check for: > > file server is hung trying to talk to pts > file server is hung trying to recall callbacks from unresponsive clients > > There may be clues in your FileLog. I'd be suspicious of 128.104.3.108 and > 128.104.3.109. They are unreachable right now, at least from here. If they > are doing thousands of Fetchstatuses but can't be reached by the file server > for callbacks, that could foul things up. Is that subnet behind a firewall? I'm not sure. I'll contact the folks responsible for those machines and see what they know. > Your message was delayed to the list by a couple of weeks. Is the > 1.4.4 file server any better now than the 1.4.1? 1.4.4 has been better than 1.4.1, but we still experienced a week or so of badness about a week after the upgrade. Since then (ie, the last 10 days or so), we haven't had any problems. As Derrick says, we'll probably want to upgrade to 1.4.5 when it's available. For now, I can't find any evidence of misconfigured clients, but I'll be sure to look harder for them next time. Thanks! -- [Will Maier]-----------------[willmaier@ml1.net|http://www.lfod.us/] From rra@stanford.edu Tue Oct 9 21:36:41 2007 From: rra@stanford.edu (Russ Allbery) Date: Tue, 09 Oct 2007 13:36:41 -0700 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <13067818.post@talk.nabble.com> (Norbert Schuch's message of "Fri, 5 Oct 2007 14:38:32 -0700 (PDT)") References: <200708121157.02874.dirk.heinrichs@online.de> <13067818.post@talk.nabble.com> Message-ID: <87k5pw9g9y.fsf@windlord.stanford.edu> Norbert Schuch writes: > I had the same problem -- No such file or directory errors -- after > upgrading the 2.6.21 (self-compiled) kernel to the most recent Debian > sources. After some experiments, I figured out that it probably depends > on the gcc version. The new kernel has been compiled with gcc-4.2, and > indeed no kernel in the 2.6.21 series works with openafs if compiled > with gcc-4.2. If I however compile it with gcc-4.0, it works again with > openafs. > So trying a different gcc version might help. It'll be fixed in Debian unstable as soon as I can find a free hour or two. -- Russ Allbery (rra@stanford.edu) From rra@stanford.edu Tue Oct 9 21:47:16 2007 From: rra@stanford.edu (Russ Allbery) Date: Tue, 09 Oct 2007 13:47:16 -0700 Subject: [OpenAFS] Re: Chronic blocked connections on fileserver In-Reply-To: <20071009202001.GD14302@lass.lfod.us> (Will Maier's message of "Tue, 9 Oct 2007 15:20:01 -0500") References: <20070924132346.GX19736@lass.lfod.us> <20070924132458.GY19736@lass.lfod.us> <20070924133536.GA22773@citi.umich.edu> <20070928154845.GD28023@lass.lfod.us> <20071009200706.GA22604@citi.umich.edu> <20071009202001.GD14302@lass.lfod.us> Message-ID: <87bqb89fsb.fsf@windlord.stanford.edu> Will Maier writes: > 1.4.4 has been better than 1.4.1, but we still experienced a week or so > of badness about a week after the upgrade. Since then (ie, the last 10 > days or so), we haven't had any problems. > As Derrick says, we'll probably want to upgrade to 1.4.5 when it's > available. For now, I can't find any evidence of misconfigured clients, > but I'll be sure to look harder for them next time. We had a great deal of instability and occasional clients simply failing to talk to certain AFS servers until we upgraded the file servers to something close to what's in STABLE right now. So far, so good after that. -- Russ Allbery (rra@stanford.edu) From jblaine@kickflop.net Wed Oct 10 19:50:24 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Wed, 10 Oct 2007 14:50:24 -0400 Subject: [OpenAFS] 1.4.4 and Solaris 10 build problem Message-ID: <470D1EF0.6000708@kickflop.net> Sun Studio 11 Any ideas anyone? ./configure --enable-transarc-paths ... make dest ... /opt/SUNWspro/bin/cc -I. -I.. -I../nfs -I/joshua.mitre.org/tmp/openafs-1.4.4/src -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/SOLARIS -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rx/SOLARIS -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad/domestic -I/joshua.mitre.org/tmp/openafs-1.4.4/src/util -I/joshua.mitre.org/tmp/openafs-1.4.4/src -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/SOLARIS -I/joshua.mitre.org/tmp/openafs-1.4.4/src/util -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config -I/joshua.mitre.org/tmp/openafs-1.4.4/src/fsint -I/joshua.mitre.org/tmp/openafs-1.4.4/src/vlserver -I/joshua.mitre.org/tmp/openafs-1.4.4/include -I/joshua.mitre.org/tmp/openafs-1.4.4/include/afs -O -I. -I.. -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config -DAFSDEBUG -DKERNEL -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn -xarch=v9 -o afs_analyze.o -c /joshua.mitre.org/tmp/openafs-1.4.4/src/afs/afs_analyze.c "../sys/zone.h", line 16: cannot find include file: "../sys/zone.h", line 109: warning: no explicit type given "../sys/zone.h", line 109: warning: syntax requires ";" after last struct/union member ... From deengert@anl.gov Wed Oct 10 20:57:24 2007 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 10 Oct 2007 14:57:24 -0500 Subject: [OpenAFS] 1.4.4 and Solaris 10 build problem In-Reply-To: <470D1EF0.6000708@kickflop.net> References: <470D1EF0.6000708@kickflop.net> Message-ID: <470D2EA4.4010006@anl.gov> Jeff Blaine wrote: > Sun Studio 11 > > Any ideas anyone? does /usr/include/sys/tsol/label.h exist? Its on our solaris 10 systems, even the older ones. Google for tsol/label.h Other people are having problems finding it for other programs too. Someone says it is included with kernel patch 120012-14 > > ./configure --enable-transarc-paths > ... > make dest > ... > /opt/SUNWspro/bin/cc -I. -I.. -I../nfs > -I/joshua.mitre.org/tmp/openafs-1.4.4/src > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/SOLARIS > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rx/SOLARIS > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad/domestic > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/util > -I/joshua.mitre.org/tmp/openafs-1.4.4/src > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/SOLARIS > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/util > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/fsint > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/vlserver > -I/joshua.mitre.org/tmp/openafs-1.4.4/include > -I/joshua.mitre.org/tmp/openafs-1.4.4/include/afs -O -I. -I.. > -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config -DAFSDEBUG -DKERNEL > -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn > -xarch=v9 -o afs_analyze.o -c > /joshua.mitre.org/tmp/openafs-1.4.4/src/afs/afs_analyze.c > "../sys/zone.h", line 16: cannot find include file: > "../sys/zone.h", line 109: warning: no explicit type given > "../sys/zone.h", line 109: warning: syntax requires ";" after last > struct/union member > ... > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From sebby@anl.gov Wed Oct 10 21:43:15 2007 From: sebby@anl.gov (Brian Sebby) Date: Wed, 10 Oct 2007 15:43:15 -0500 Subject: [OpenAFS] 1.4.4 and Solaris 10 build problem In-Reply-To: <470D2EA4.4010006@anl.gov> References: <470D1EF0.6000708@kickflop.net> <470D2EA4.4010006@anl.gov> Message-ID: <20071010204315.GA20599@nausicaa.cis.anl.gov> As a note, the patch that includes it is 120011-14 on Sparc, and 120012-14 on x86. It's the most recent kernel patch. I also found it in patch 120050-06 for Sparc, and 120051-06 for x86, which is listed as the "SunOS 5.10: usermod patch". This patch was obsoleted by 120011-14/120012-14. Brian On Wed, Oct 10, 2007 at 02:57:24PM -0500, Douglas E. Engert wrote: > > > Jeff Blaine wrote: > >Sun Studio 11 > > > >Any ideas anyone? > > does /usr/include/sys/tsol/label.h exist? > > Its on our solaris 10 systems, even the older ones. > > Google for tsol/label.h > Other people are having problems finding it > for other programs too. > Someone says it is included with kernel patch 120012-14 > > > > > > >./configure --enable-transarc-paths > >... > >make dest > >... > >/opt/SUNWspro/bin/cc -I. -I.. -I../nfs > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/SOLARIS > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/config > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/rx/SOLARIS > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad/domestic > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/util > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/SOLARIS > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/util > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/config > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/fsint > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/vlserver > >-I/joshua.mitre.org/tmp/openafs-1.4.4/include > >-I/joshua.mitre.org/tmp/openafs-1.4.4/include/afs -O -I. -I.. > >-I/joshua.mitre.org/tmp/openafs-1.4.4/src/config -DAFSDEBUG -DKERNEL > >-DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn > >-xarch=v9 -o afs_analyze.o -c > >/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/afs_analyze.c > >"../sys/zone.h", line 16: cannot find include file: > >"../sys/zone.h", line 109: warning: no explicit type given > >"../sys/zone.h", line 109: warning: syntax requires ";" after last > >struct/union member > >... > >_______________________________________________ > >OpenAFS-info mailing list > >OpenAFS-info@openafs.org > >https://lists.openafs.org/mailman/listinfo/openafs-info > > > > > > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Brian Sebby (sebby@anl.gov) | Unix and Operation Services Phone: +1 630.252.9935 | Computing and Information Systems Fax: +1 630.252.4601 | Argonne National Laboratory From jblaine@kickflop.net Wed Oct 10 21:57:17 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Wed, 10 Oct 2007 16:57:17 -0400 Subject: [OpenAFS] 1.4.4 and Solaris 10 build problem In-Reply-To: <20071010204315.GA20599@nausicaa.cis.anl.gov> References: <470D1EF0.6000708@kickflop.net> <470D2EA4.4010006@anl.gov> <20071010204315.GA20599@nausicaa.cis.anl.gov> Message-ID: <470D3CAD.5070000@kickflop.net> Thanks for the help, Brian and Doug. I'll see what I can do. I DETEST Sun Update Connection, BTW. I've found it to be awful, almost never work properly when registering a system, and provides almost completely useless error messages. Brian Sebby wrote: > As a note, the patch that includes it is 120011-14 on Sparc, and 120012-14 > on x86. It's the most recent kernel patch. > > I also found it in patch 120050-06 for Sparc, and 120051-06 for x86, which > is listed as the "SunOS 5.10: usermod patch". This patch was obsoleted > by 120011-14/120012-14. > > > Brian > > On Wed, Oct 10, 2007 at 02:57:24PM -0500, Douglas E. Engert wrote: >> >> Jeff Blaine wrote: >>> Sun Studio 11 >>> >>> Any ideas anyone? >> does /usr/include/sys/tsol/label.h exist? >> >> Its on our solaris 10 systems, even the older ones. >> >> Google for tsol/label.h >> Other people are having problems finding it >> for other programs too. >> Someone says it is included with kernel patch 120012-14 >> >> >> >>> ./configure --enable-transarc-paths >>> ... >>> make dest >>> ... >>> /opt/SUNWspro/bin/cc -I. -I.. -I../nfs >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/SOLARIS >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rx/SOLARIS >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad/domestic >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/util >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/afs/SOLARIS >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/util >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/rxkad >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/fsint >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/vlserver >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/include >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/include/afs -O -I. -I.. >>> -I/joshua.mitre.org/tmp/openafs-1.4.4/src/config -DAFSDEBUG -DKERNEL >>> -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn >>> -xarch=v9 -o afs_analyze.o -c >>> /joshua.mitre.org/tmp/openafs-1.4.4/src/afs/afs_analyze.c >>> "../sys/zone.h", line 16: cannot find include file: >>> "../sys/zone.h", line 109: warning: no explicit type given >>> "../sys/zone.h", line 109: warning: syntax requires ";" after last >>> struct/union member >>> ... >>> _______________________________________________ >>> OpenAFS-info mailing list >>> OpenAFS-info@openafs.org >>> https://lists.openafs.org/mailman/listinfo/openafs-info >>> >>> >> -- >> >> Douglas E. Engert >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info > From hans@MPA-Garching.MPG.DE Thu Oct 11 14:33:54 2007 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Thu, 11 Oct 2007 15:33:54 +0200 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <47091414.4090800@technoconseil.com> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> Message-ID: <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote: > Anyone care to test out the attached patch for src/dir/dir.c >=20 > The hashing code in the DirHash() function relies on integer overflow t= o=20 > make the hval value turn into a negative value. gcc 4.2 assumes that=20 > this value can never go negative and optimizes out the (hval < 0) test. >=20 > Marc >=20 > diff -u -r1.24 dir.c > --- src/dir/dir.c 13 Oct 2005 15:12:12 -0000 1.24 > +++ src/dir/dir.c 7 Oct 2007 17:10:37 -0000 > @@ -478,8 +478,9 @@ > { > /* Hash a string to a number between 0 and NHASHENT. */ > register unsigned char tc; > - register int hval; > + unsigned long hval; > register int tval; > + > hval =3D 0; > while ((tc =3D (*string++))) { > hval *=3D 173; > @@ -488,7 +489,7 @@ > tval =3D hval & (NHASHENT - 1); > if (tval =3D=3D 0) > return tval; > - else if (hval < 0) > + else if (hval >=3D 1<<31) > tval =3D NHASHENT - tval; > return tval; > } this patch is fine for architectures where the size of "unsigned long" is 4 bytes. But on the x86_64 architecture this will not work, because the size is 8 bytes. One can use "unsigned int". HW --=20 Hans-Werner Paulsen hans@MPA-Garching.MPG.DE MPI f=FCr Astrophysik Tel 089-30000-2602 Karl-Schwarzschild-Str. 1 Fax 089-30000-2235=09 D-85741 Garching From carson@taltos.org Fri Oct 12 01:02:58 2007 From: carson@taltos.org (Carson Gaspar) Date: Thu, 11 Oct 2007 20:02:58 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> Message-ID: <470EB9B2.5030305@taltos.org> Hans-Werner Paulsen wrote: > On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote: >> + else if (hval >= 1<<31) > this patch is fine for architectures where the size of "unsigned long" > is 4 bytes. But on the x86_64 architecture this will not work, because > the size is 8 bytes. One can use "unsigned int". Ummm... no. This whole thing is way too fragile. If you care about how many bits the variable has, you MUST use something like uint32_t. Or you can not care, and use sizeof() to generate your comparison. But you MUST NOT use "int" or "long" and hard-code bit shifts. -- Carson From marc.dionne@technoconseil.com Fri Oct 12 03:43:17 2007 From: marc.dionne@technoconseil.com (Marc Dionne) Date: Thu, 11 Oct 2007 22:43:17 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <470EB9B2.5030305@taltos.org> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> <470EB9B2.5030305@taltos.org> Message-ID: <470EDF45.5090702@technoconseil.com> Carson Gaspar wrote: > Hans-Werner Paulsen wrote: >> On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote: > >>> + else if (hval >= 1<<31) > >> this patch is fine for architectures where the size of "unsigned long" >> is 4 bytes. But on the x86_64 architecture this will not work, because >> the size is 8 bytes. One can use "unsigned int". > > Ummm... no. This whole thing is way too fragile. If you care about how > many bits the variable has, you MUST use something like uint32_t. Or you > can not care, and use sizeof() to generate your comparison. But you MUST > NOT use "int" or "long" and hard-code bit shifts. Sure enough - with the original patch I was trying to confirm that this was indeed the issue, and didn't try to be generic. How about something like this, with an unsigned int for hval: else if (hval >= 1<<(sizeof(hval)*8-1)) which seems functionally equivalent to the original code and not dependent on the size of hval. Now I'm curious as to why the specific value returned by DirHash even matters. Even with the gcc bug it would be consistent for a given string on the same client. Does this value have to match what's computed for the same string on the file server side? (looks like DirHash is also used in fileserver) If so, it looks like the original code could produce different values with different size ints on the server and client. Marc From matt@linuxbox.com Fri Oct 12 03:52:50 2007 From: matt@linuxbox.com (Matt Benjamin) Date: Thu, 11 Oct 2007 22:52:50 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <470EDF45.5090702@technoconseil.com> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> <470EB9B2.5030305@taltos.org> <470EDF45.5090702@technoconseil.com> Message-ID: <470EE182.8020505@linuxbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I think Derrick was being careful when he said it a) fixed the issue and b) was harmless. Matt Marc Dionne wrote: > Carson Gaspar wrote: >> Hans-Werner Paulsen wrote: >>> On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote: >> >>>> + else if (hval >= 1<<31) >> >>> this patch is fine for architectures where the size of "unsigned long" >>> is 4 bytes. But on the x86_64 architecture this will not work, because >>> the size is 8 bytes. One can use "unsigned int". >> >> Ummm... no. This whole thing is way too fragile. If you care about how >> many bits the variable has, you MUST use something like uint32_t. Or >> you can not care, and use sizeof() to generate your comparison. But >> you MUST NOT use "int" or "long" and hard-code bit shifts. > > Sure enough - with the original patch I was trying to confirm that this > was indeed the issue, and didn't try to be generic. > > - -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDuGCJiSUUSaRdSURCC7EAJ9QSM14weKgsjT0EZcUnS9O0cSCUACgj+mb P7FrrFgD3q4cp6GKWKBqRR0= =LHDI -----END PGP SIGNATURE----- From shadow@gmail.com Fri Oct 12 03:54:12 2007 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 11 Oct 2007 22:54:12 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <470EB9B2.5030305@taltos.org> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> <470EB9B2.5030305@taltos.org> Message-ID: ------=_Part_10227_22493546.1192157652333 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline You wacky kids and your excessive widereplies. Anyway, if I have time to do testing, I will. Otherwise, if someone wants to do a clean version of this, please do. On 10/11/07, Carson Gaspar wrote: > > Hans-Werner Paulsen wrote: > > On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote: > > >> + else if (hval >= 1<<31) > > > this patch is fine for architectures where the size of "unsigned long" > > is 4 bytes. But on the x86_64 architecture this will not work, because > > the size is 8 bytes. One can use "unsigned int". > > Ummm... no. This whole thing is way too fragile. If you care about how > many bits the variable has, you MUST use something like uint32_t. Or you > can not care, and use sizeof() to generate your comparison. But you MUST > NOT use "int" or "long" and hard-code bit shifts. > > ------=_Part_10227_22493546.1192157652333 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline You wacky kids and your excessive widereplies.

Anyway, if I have time to do testing, I will. Otherwise, if someone wants to do a clean version of this, please do.

On 10/11/07, Carson Gaspar <carson@taltos.org> wrote:
Hans-Werner Paulsen wrote:
> On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote:

>> +    else if (hval >= 1<<31)

> this patch is fine for architectures where the size of "unsigned long"
> is 4 bytes. But on the x86_64 architecture this will not work, because
> the size is 8 bytes. One can use "unsigned int".

Ummm... no. This whole thing is way too fragile. If you care about how
many bits the variable has, you MUST use something like uint32_t. Or you
can not care, and use sizeof() to generate your comparison. But you MUST
NOT use "int" or "long" and hard-code bit shifts.


------=_Part_10227_22493546.1192157652333-- From jaltman@columbia.edu Fri Oct 12 04:19:50 2007 From: jaltman@columbia.edu (Jeffrey Altman) Date: Thu, 11 Oct 2007 23:19:50 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <470EDF45.5090702@technoconseil.com> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> <470EB9B2.5030305@taltos.org> <470EDF45.5090702@technoconseil.com> Message-ID: <470EE7D6.1050904@columbia.edu> This is a cryptographically signed message in MIME format. --------------ms090602050004020106010004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Marc Dionne wrote: > Now I'm curious as to why the specific value returned by DirHash even > matters. Even with the gcc bug it would be consistent for a given > string on the same client. Does this value have to match what's > computed for the same string on the file server side? The hash is used to look up the name in the AFS3 directory hash table that is received by the client from the file server. > (looks like > DirHash is also used in fileserver) If so, it looks like the original > code could produce different values with different size ints on the > server and client. Good thing we are lucky that 'int' is 32-bits on all of the platforms we care about. I agree this should be afs_int32. Jeffrey Altman --------------ms090602050004020106010004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEFd5KHFJEUHRe0PJhTA+3HwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTQ0MVoX DTA4MDUzMDA2MTQ0MVowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvF3HS+02 BwCXdkA4QiYBXMSCC3Qmom5k9kI4I//iPbt4z9GDiDcG6THjKOlzLjnQcYdZHkQwj8qPIF4J 7BeaBA4alJq37j2jKxV0sXTiX+SszT44cZF3HclDq0J+8a7L/6+gYxkkPhIU+2YGFWS1JRxt QMeG/tRk8LNmgKOT4tSKLGMrkh7VTSOlbfBZxU0sP388SGcTQ5HCUCBunFUMloFMieIQHztA 4FnxauwuXP/9Yj7A6FnvIJAy9i1oQeJYcTxmV57OzDCOza5r71OwgxPxbjFYDTkZDj+tUKaY pvDfWGnmWYENt8uoDVgKOFom443BN0XtkRHgrnm5rlKDwQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GB ALKxXvMMUQrYhEAzjynS32j3UAKVBH2cCvizNRV87E+ozrOufSQk9eAsRDxBYpv/WllIy/Hb RZ4MCo+utK48ngeDxH5peRfinaMO3tCK+FaAKFcMYh4bGZkiW6HSn1pdQKnCTi0aCU55zz4X gA4aueid3eIz4gAhVKNQgaWbgjNKMIIDBzCCAnCgAwIBAgIQV3kocUkRQdF7Q8mFMD7cfDAN BgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDcwNTMxMDYxNDQxWhcNMDgwNTMwMDYxNDQxWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC8XcdL7TYHAJd2QDhCJgFcxIILdCaibmT2Qjgj/+I9u3jP0YOI NwbpMeMo6XMuOdBxh1keRDCPyo8gXgnsF5oEDhqUmrfuPaMrFXSxdOJf5KzNPjhxkXcdyUOr Qn7xrsv/r6BjGSQ+EhT7ZgYVZLUlHG1Ax4b+1GTws2aAo5Pi1IosYyuSHtVNI6Vt8FnFTSw/ fzxIZxNDkcJQIG6cVQyWgUyJ4hAfO0DgWfFq7C5c//1iPsDoWe8gkDL2LWhB4lhxPGZXns7M MI7NrmvvU7CDE/FuMVgNORkOP61Qppim8N9YaeZZgQ23y6gNWAo4WibjjcE3Re2REeCuebmu UoPBAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAsrFe8wxRCtiEQDOPKdLfaPdQApUEfZwK+LM1FXzs T6jOs659JCT14CxEPEFim/9aWUjL8dtFngwKj660rjyeB4PEfml5F+Kdow7e0Ir4VoAoVwxi HhsZmSJbodKfWl1AqcJOLRoJTnnPPheADhq56J3d4jPiACFUo1CBpZuCM0owggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEFd5KHFJEUHRe0PJhTA+3HwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMDEyMDMxOTUw WjAjBgkqhkiG9w0BCQQxFgQUiS64x/HRFkK8PuvkHsj0TJgQcR4wUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBXeShxSRFB0XtDyYUwPtx8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhBXeShxSRFB0XtDyYUwPtx8MA0GCSqGSIb3DQEBAQUABIIBAI0O1RgxLtl96nArwhVOhCRi gvqP2lXYW9yqvu73g77uNGwA8skK1xHvKViuyLriyqT+Hs3B7GCdSCEIgt5/404gKUvWimxF lWzvgsIrw1AeOYypGIGYFSrtLq7EQ533fGCqTcbVC9M6hsyMvKod9Fxk5CnCgZ4/Nw/AOwNg eJhGYR69YysgvIjISC+DBDtaAb1hWWM1rLwM7M/QNTIqHnLzlkRM8AXeCG5anVVdfbwkqcz5 oILgZxpt0ZJz3OA3SFNY3+kG8uSGEvNicnM5HPAI4BIYGh7jB8gBTiPA8ln1RbisZHt8rHg2 6H1YAenU7nElVgtFwUFG4bN81qnyAWcAAAAAAAA= --------------ms090602050004020106010004-- From shadow@gmail.com Fri Oct 12 04:20:35 2007 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 11 Oct 2007 23:20:35 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <470EE7D6.1050904@columbia.edu> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> <470EB9B2.5030305@taltos.org> <470EDF45.5090702@technoconseil.com> <470EE7D6.1050904@columbia.edu> Message-ID: ------=_Part_10273_15211296.1192159235287 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/11/07, Jeffrey Altman wrote: > > Marc Dionne wrote: > > Now I'm curious as to why the specific value returned by DirHash even > > matters. Even with the gcc bug it would be consistent for a given > > string on the same client. Does this value have to match what's > > computed for the same string on the file server side? > > The hash is used to look up the name in the AFS3 directory hash table > that is received by the client from the file server. > > > (looks like > > DirHash is also used in fileserver) If so, it looks like the original > > code could produce different values with different size ints on the > > server and client. > > Good thing we are lucky that 'int' is 32-bits on all of the platforms we > care about. I agree this should be afs_int32. the entire dir package is bad about specifying int, long or afs_int32; making stylistic changes now is probably not the best idea. ------=_Part_10273_15211296.1192159235287 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/11/07, Jeffrey Altman <jaltman@columbia.edu> wrote:
Marc Dionne wrote:
> Now I'm curious as to why the specific value returned by DirHash even
> matters.  Even with the gcc bug it would be consistent for a given
> string on the same client.  Does this value have to match what's
> computed for the same string on the file server side?

The hash is used to look up the name in the AFS3 directory hash table
that is received by the client from the file server.

> (looks like
> DirHash is also used in fileserver) If so, it looks like the original
> code could produce different values with different size ints on the
> server and client.

Good thing we are lucky that 'int' is 32-bits on all of the platforms we
care about.   I agree this should be afs_int32.

the entire dir package is bad about specifying int, long or afs_int32; making stylistic changes now is probably not the best idea.


------=_Part_10273_15211296.1192159235287-- From marc.dionne@technoconseil.com Fri Oct 12 03:45:08 2007 From: marc.dionne@technoconseil.com (Marc Dionne) Date: Thu, 11 Oct 2007 22:45:08 -0400 Subject: [OpenAFS] Strange access problems on one client In-Reply-To: <470EB9B2.5030305@taltos.org> References: <200708121157.02874.dirk.heinrichs@online.de> <13077327.post@talk.nabble.com> <47091414.4090800@technoconseil.com> <20071011133354.GA29669@ncq-5.MPA-Garching.MPG.DE> <470EB9B2.5030305@taltos.org> Message-ID: <470EDFB4.7090607@technoconseil.com> Carson Gaspar wrote: > Hans-Werner Paulsen wrote: >> On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote: > >>> + else if (hval >= 1<<31) > >> this patch is fine for architectures where the size of "unsigned long" >> is 4 bytes. But on the x86_64 architecture this will not work, because >> the size is 8 bytes. One can use "unsigned int". > > Ummm... no. This whole thing is way too fragile. If you care about how > many bits the variable has, you MUST use something like uint32_t. Or you > can not care, and use sizeof() to generate your comparison. But you MUST > NOT use "int" or "long" and hard-code bit shifts. Sure enough - with the original patch I was trying to confirm that this was indeed the issue, and didn't try to be generic. How about something like this, with an unsigned int for hval: else if (hval >= 1<<(sizeof(hval)*8-1)) which seems functionally equivalent to the original code and not dependent on the size of hval. Now I'm curious as to why the specific value returned by DirHash even matters. Even with the gcc bug it would be consistent for a given string on the same client. Does this value have to match what's computed for the same string on the file server side? (looks like DirHash is also used in fileserver) If so, it looks like the original code could produce different values with different size ints on the server and client. Marc From botsch@cnf.cornell.edu Fri Oct 12 20:29:26 2007 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Fri, 12 Oct 2007 15:29:26 -0400 Subject: [OpenAFS] dots in usernames Message-ID: <20071012192926.GT26707@puff.cnf.cornell.edu> With Kerberos V, dots in usernames should now be fine, right? So, are there still known issues with dots in usernames? Or should it be working? It looks like, from this end, aklog autoreg doesn't work and pts doesn't work (even though I can create a user in pts as admin) and I appear to have tokens. As the user with the dot in the username, the tokens are discarded with rxkad error 19270407 (rxk).7 = security object was passed a bad ticket Openafs1.4.2 - no kaserver - just "pure" K5 - haven't tried Windows, yet. Only trying with crossrealm users. thanks. -- ******************************** David William Botsch Programmer/Analyst CNF Computing botsch@cnf.cornell.edu ******************************** From jaltman@secure-endpoints.com Fri Oct 12 20:44:12 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 12 Oct 2007 15:44:12 -0400 Subject: [OpenAFS] dots in usernames In-Reply-To: <20071012192926.GT26707@puff.cnf.cornell.edu> References: <20071012192926.GT26707@puff.cnf.cornell.edu> Message-ID: <470FCE8C.6090100@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms070709060908010809060306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave Botsch wrote: > With Kerberos V, dots in usernames should now be fine, right? > > So, are there still known issues with dots in usernames? Or should it be > working? We have received no patch to remove the "dot in first component" check. Therefore, user names with dots are still not accepted unless you are applying your own custom mod to the source. Jeffrey Altman --------------ms070709060908010809060306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMTIxOTQ0MTJaMCMGCSqGSIb3DQEJBDEWBBSfcear 2vrvE5Qdj/FvAiHDzISuDDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEApjeldwmsPeaSTIEqXchticUwklUojKcqcfJbdjYv5GZ8MPgaj60N ywj96vih9dtj/d1MyPBfMqhsJAO8FCez9ZeNqQT3gUWDcYCQm79YDA5wa9HowTpU2wRu5xk9 9NfDI1+cRG+d9Fy3PdqDPuhm2BeGJnyBNnDgThyonCQYc0Z+msm46f++0f174NBOnVwbnjbF wLXr7CTjQrqB/y+GyUfRoSFAjSYTz2bivGBf9a5WkWroN2rjVWpe5uTxrXqHf3UKb3zM9AQq dk1sWVzZLQ7eTyOcoO6tYI3Qm7r02wiufnXFmDsv8W1azMJw/+KO+SXGe4IEy7ERc5Q5IJHz hwAAAAAAAA== --------------ms070709060908010809060306-- From sdevine@msu.edu Fri Oct 12 21:17:15 2007 From: sdevine@msu.edu (Steve Devine) Date: Fri, 12 Oct 2007 16:17:15 -0400 Subject: [OpenAFS] dots in usernames In-Reply-To: <470FCE8C.6090100@secure-endpoints.com> References: <20071012192926.GT26707@puff.cnf.cornell.edu> <470FCE8C.6090100@secure-endpoints.com> Message-ID: <470FD64B.9040208@msu.edu> Jeffrey Altman wrote: > Dave Botsch wrote: > >> With Kerberos V, dots in usernames should now be fine, right? >> >> So, are there still known issues with dots in usernames? Or should it be >> working? >> > > We have received no patch to remove the "dot in first component" check. > Therefore, user names with dots are still not accepted unless you are > applying your own custom mod to the source. > > Jeffrey Altman > I don't think dots in usernames works in pts ... or is that the patch you are referring to? -- Steve Devine Network Storage & Printing Academic Computing & Network Services Michigan State University 506 Computer Center East Lansing, MI 48824-1042 1-517-432-7327 Baseball is ninety percent mental; the other half is physical. - Yogi Berra From botsch@cnf.cornell.edu Fri Oct 12 21:18:08 2007 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Fri, 12 Oct 2007 16:18:08 -0400 Subject: [OpenAFS] dots in usernames In-Reply-To: <470FCE8C.6090100@secure-endpoints.com> References: <20071012192926.GT26707@puff.cnf.cornell.edu> <470FCE8C.6090100@secure-endpoints.com> Message-ID: <20071012201808.GU26707@puff.cnf.cornell.edu> Is it nothing more than a "if dot don't allow" or is there some particular reason that if is there (allowing the dot in the username would break something else)? On Fri, Oct 12, 2007 at 03:44:12PM -0400, Jeffrey Altman wrote: > Dave Botsch wrote: > > With Kerberos V, dots in usernames should now be fine, right? > > > > So, are there still known issues with dots in usernames? Or should it be > > working? > > We have received no patch to remove the "dot in first component" check. > Therefore, user names with dots are still not accepted unless you are > applying your own custom mod to the source. > > Jeffrey Altman -- ******************************** David William Botsch Programmer/Analyst CNF Computing botsch@cnf.cornell.edu ******************************** From rra@stanford.edu Fri Oct 12 21:19:08 2007 From: rra@stanford.edu (Russ Allbery) Date: Fri, 12 Oct 2007 13:19:08 -0700 Subject: [OpenAFS] dots in usernames In-Reply-To: <470FD64B.9040208@msu.edu> (Steve Devine's message of "Fri, 12 Oct 2007 16:17:15 -0400") References: <20071012192926.GT26707@puff.cnf.cornell.edu> <470FCE8C.6090100@secure-endpoints.com> <470FD64B.9040208@msu.edu> Message-ID: <87ir5c9jcz.fsf@windlord.stanford.edu> Steve Devine writes: > Jeffrey Altman wrote: >> We have received no patch to remove the "dot in first component" check. >> Therefore, user names with dots are still not accepted unless you are >> applying your own custom mod to the source. > I don't think dots in usernames works in pts ... or is that the patch you > are referring to? That's the patch. We want it to work, and there was some discussion of the right way of making it work without introducing other problems, but unfortunately no one has yet had time to implement any of the proposed solutions. -- Russ Allbery (rra@stanford.edu) From rra@stanford.edu Fri Oct 12 21:23:01 2007 From: rra@stanford.edu (Russ Allbery) Date: Fri, 12 Oct 2007 13:23:01 -0700 Subject: [OpenAFS] dots in usernames In-Reply-To: <20071012201808.GU26707@puff.cnf.cornell.edu> (Dave Botsch's message of "Fri, 12 Oct 2007 16:18:08 -0400") References: <20071012192926.GT26707@puff.cnf.cornell.edu> <470FCE8C.6090100@secure-endpoints.com> <20071012201808.GU26707@puff.cnf.cornell.edu> Message-ID: <87ejg09j6i.fsf@windlord.stanford.edu> Dave Botsch writes: > Is it nothing more than a "if dot don't allow" or is there some > particular reason that if is there (allowing the dot in the username > would break something else)? The problem is that AFS uses Kerberos v4 naming for PTS entries, and when you convert Kerberos v5 instances to Kerberos v4, you can't tell the difference between rra.root and rra/root. Since that ambiguity could potentially cause security issues if a principal with a period in it happened to map to a privileged instance, the current code takes the maximally conservative approach of rejecting any Kerberos v5 principal containing a period. There was some discussion a while back about the possible acceptable solutions that wouldn't run the risk of introducing a security issue due to name conflicts. The real long-term solution, of course, is to teach PTS about Kerberos v5 principal names, but that's a reasonably large chunk of work. -- Russ Allbery (rra@stanford.edu) From jaltman@secure-endpoints.com Fri Oct 12 21:29:16 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 12 Oct 2007 16:29:16 -0400 Subject: [OpenAFS] dots in usernames In-Reply-To: <20071012201808.GU26707@puff.cnf.cornell.edu> References: <20071012192926.GT26707@puff.cnf.cornell.edu> <470FCE8C.6090100@secure-endpoints.com> <20071012201808.GU26707@puff.cnf.cornell.edu> Message-ID: <470FD91C.2090101@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms060100060803060605050103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave Botsch wrote: > Is it nothing more than a "if dot don't allow" or is there some particular > reason that if is there (allowing the dot in the username would break something > else)? There are several threads on this topic. I really would hate to repeat it all. In short, Kerberos v4 principals use 'dot' as the separator between the 'user' and the 'instance'. As in "dave@CORNELL.EDU" and "dave.admin@CORNELL.EDU". Kerberos v5 internally uses multiple length encoded components which are visibly displayed with slashes. When Kerberos v5 is used, the names are converted into Kerberos v4 form. So "dave/admin@CORNELL.EDU" becomes "dave.admin@CORNELL.EDU". Now if there was a user "dave.admin" such that there was a dave.admin@CORNELL.EDU single component Kerberos v5 name, it would collide with "dave/admin@CORNELL.EDU" within the PTS database. That is why there is the check. To prevent this collision. There was a description posted to openafs-devel some time back describing the patch that the Gatekeepers would accept. Jeffrey Altman --------------ms060100060803060605050103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMTIyMDI5MTZaMCMGCSqGSIb3DQEJBDEWBBQZpGsh 3fVlomSf9r6wlSGFuiNmDTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAYVcuUkJ4TWxeSQbTzacGObGvGQ+eIBrY0XmbS13oOkX6VvxjS09Y iQzHbJV2k6dIScHA42epYu40alzFrHpXKxSYf+hp0edsOpLY2TphzcI4pi6DjvKZe3DrX3sJ 0pCEnLs1Tz9zk7WoNb40unWniMo0tcLlRHLnkhMUUZ6ZfZj1a02Jo6HtChp7RFa2qy9vZRW/ 2+w1kCk3fH7Q0hxvEJGIc5cyWWQ8m9gJCET5+1UTw7yuyWzixWyrhZOEMEevs+aAEzacm/vJ vFNVXsYXhE+5XTbrag9rbdTTL42W9DO2rJNCebbTrXvBY1u9klGMktlYKifChBsKJ05YF5uu TwAAAAAAAA== --------------ms060100060803060605050103-- From boyland@cs.uwm.edu Sat Oct 13 18:28:06 2007 From: boyland@cs.uwm.edu (John Tang Boyland) Date: Sat, 13 Oct 2007 12:28:06 -0500 Subject: [OpenAFS] Re: more on Windows Vista problem Message-ID: <6131.1192296486@pabst.cs.uwm.edu> Sorry for the delay: I hadn't convinced myself yet this email was necessary. But, for the record: using 'aklog.exe' showed that the system was attempting to get tickets from the wrong realm. The student re-installed OpenAFS again a few more times and things started working. John From jaltman@secure-endpoints.com Sat Oct 13 22:46:50 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Sat, 13 Oct 2007 17:46:50 -0400 Subject: [OpenAFS] Re: more on Windows Vista problem In-Reply-To: <6131.1192296486@pabst.cs.uwm.edu> References: <6131.1192296486@pabst.cs.uwm.edu> Message-ID: <47113CCA.5030305@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms020303040002040603080206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit John Tang Boyland wrote: > Sorry for the delay: I hadn't convinced myself yet this email was necessary. > > But, for the record: using 'aklog.exe' showed that the system > was attempting to get tickets from the wrong realm. > The student re-installed OpenAFS again a few more times and > things started working. > John The way the realm is determined for a realm is: * take the address of a random vlserver for the cell * perform a reverse DNS lookup on it * perform a domain to realm mapping on the resulting hostname This produces the realm to be used. Jeffrey Altman --------------ms020303040002040603080206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMTMyMTQ2NTBaMCMGCSqGSIb3DQEJBDEWBBQML2IX 7XwSHsAcgmaCXZgNZM5sPjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAIrXv9jWOLT93lokS1iHM6utOmD4foCACQ0pigz27cleZ/jnCF61M E70eKc7YcQx0P5O7DNudpMufp4g7MPvP3oxcL5t2wOZ4pZ/GVlOqNQl0IE4xT/VvCn4PyLOi FGtzFnhBpWyRsT4D79KGmF8wE+qMyFvvJE/nmgoj+1FX7k09Wnr5Mjr6JJSXyBbkvLa1PBsQ MKxmdBlwZrDne8Ce/+cphhHrW6FqZ+TKXAQQthAyEFD4xWWAmmcslxafO8E4Oh3P3nie2fKs NIDDuvckxcOgWyKnFZi1HGMCfN8YbxtP0R3d986XUQMFQHjrlvPBWZy2mfxmj1rpgikyX3ko ZwAAAAAAAA== --------------ms020303040002040603080206-- From anthony@communitymesh.com Sun Oct 14 22:54:55 2007 From: anthony@communitymesh.com (Anthony Wright) Date: Sun, 14 Oct 2007 22:54:55 +0100 Subject: [OpenAFS] Publishing a FUSE file system over OpenAFS Message-ID: <4712902F.1030302@communitymesh.com> I've been interested in using OpenAFS as an alternative to NFS for a while now, and most of the arguments in it's favour seem fairly compelling, but i'm struggling with one issue. I'm in the process of building a system which will use a FUSE File System which I then want to publish over a network. I can clearly understand how to do this with NFS, but from my (limited) knowledge, OpenAFS seems to be much more tightly bound to the underlying file system than NFS, and I can't see how I produce a FUSE file system, and then access that file system through an OpenAFS client. Is this something that can be done under OpenAFS and if so how? If not is there an OpenAFS API similar in concept to FUSE that would allow a user mode program to publish a file system over OpenAFS? If the answer to these two questions is no, does this mean I've found out a way in which NFS is better than OpenAFS? ;-) Many thanks, Tony Wright. From jaltman@secure-endpoints.com Sun Oct 14 23:17:16 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Sun, 14 Oct 2007 18:17:16 -0400 Subject: [OpenAFS] Publishing a FUSE file system over OpenAFS In-Reply-To: <4712902F.1030302@communitymesh.com> References: <4712902F.1030302@communitymesh.com> Message-ID: <4712956C.6010305@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080404080807000804090207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anthony Wright wrote: > I've been interested in using OpenAFS as an alternative to NFS for a > while now, and most of the arguments in it's favour seem fairly > compelling, but i'm struggling with one issue. > > I'm in the process of building a system which will use a FUSE File > System which I then want to publish over a network. I can clearly > understand how to do this with NFS, but from my (limited) knowledge, > OpenAFS seems to be much more tightly bound to the underlying file > system than NFS, and I can't see how I produce a FUSE file system, and > then access that file system through an OpenAFS client. > > Is this something that can be done under OpenAFS and if so how? If not > is there an OpenAFS API similar in concept to FUSE that would allow a > user mode program to publish a file system over OpenAFS? > > If the answer to these two questions is no, does this mean I've found > out a way in which NFS is better than OpenAFS? ;-) AFS does not publish the contents of the local file system. At least not yet. AFS stores its data within portable volumes that can be migrated between file servers and replicated to multiple file servers. The file servers do not have to use the same OS nor use the same underlying file system type. There is on-going Work on a project called hostafsd which will permit the contents of a local file system to be served using AFS3 protocol. This work is not complete. Jeffrey Altman Secure Endpoints Inc. --------------ms080404080807000804090207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMTQyMjE3MTZaMCMGCSqGSIb3DQEJBDEWBBTvnzi7 wRQxxrKy7gxycVsLaDLz1jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAHjBEumKjDwy/RG0bSiAFWpvBRzv5oHWsaoXaSs9A7QM7dzuAy55A Rz3CrMypath+6JU89JRv+FsDEmprRDyyC/LFirN4lD6VedRAmgQb33nJg91pEuNY175IPtne LYziQV6sC4blqVOnVh5Jejk6MJPF9ijalq2rNJaWOs5Zc8farJap9X4rz2g75K4uCeL1WZPM 9rrBM6S+ZPIP6c1LFMCnZWeJGpjjxj8Kf2hStuNa/6+nAB/YT+CYKp/j94UeV9APH10R3sLh g+QPjnLYihjnQQNP8Dm9NAxWceEI+IRmbx9Y91kUL52B4u7hLekpxXhWo0n5+qOuyhTybbs/ 3wAAAAAAAA== --------------ms080404080807000804090207-- From jarausch@igpm.rwth-aachen.de Mon Oct 15 10:44:54 2007 From: jarausch@igpm.rwth-aachen.de (Helmut Jarausch) Date: Mon, 15 Oct 2007 11:44:54 +0200 (CEST) Subject: [OpenAFS] linux kernel-2.6.23 problem? Message-ID: Hi, I've tried to build OpenAFS-1.5.19 (the lastest version on my GenToo box) with the 2.6.23 kernel. It fails with .../openafs-1.5.19/src/libafs/MODLOAD-2.6.23-gentoo-MP/rx_kmutex.c:125: error: 'struct task_struct' has no member named 'thread_info' Is this a known problem or is there a version cooperating nice with the new Linux kernel? Many thanks for a hint, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany From rra@stanford.edu Mon Oct 15 08:46:32 2007 From: rra@stanford.edu (Russ Allbery) Date: Mon, 15 Oct 2007 00:46:32 -0700 Subject: [OpenAFS] linux kernel-2.6.23 problem? In-Reply-To: (Helmut Jarausch's message of "Mon, 15 Oct 2007 11:44:54 +0200 (CEST)") References: Message-ID: <87myuklt0n.fsf@windlord.stanford.edu> Helmut Jarausch writes: > I've tried to build OpenAFS-1.5.19 (the lastest version on my GenToo > box) with the 2.6.23 kernel. > It fails with > .../openafs-1.5.19/src/libafs/MODLOAD-2.6.23-gentoo-MP/rx_kmutex.c:125: > error: 'struct task_struct' has no member named 'thread_info' > Is this a known problem or is there a version cooperating nice with the > new Linux kernel? Yes, try the just-released 1.4.5 release candidate. (1.5.x is not recommended for Linux in general unless you're an OpenAFS developer.) -- Russ Allbery (rra@stanford.edu) From rtb@pclella.cern.ch Mon Oct 15 09:26:50 2007 From: rtb@pclella.cern.ch (Rainer Toebbicke) Date: Mon, 15 Oct 2007 10:26:50 +0200 Subject: [OpenAFS] "vos examine -extended" - statistics not reset @ midnight Message-ID: <4713244A.6090407@pclella.cern.ch> This is a multi-part message in MIME format. --------------040005060008020802060107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The "extended" statistics provided by "vos examine -extended" are not properly reset @ midnight. That is, they are actually reset correctly, however "vos examine" does not get the copy from the fileserver, but from the volume header. The code there to deal with out-of-date statistics correctly sets the number of accesses to 0, but leaves the extended statistics at their old value. You can therefore end up with volumes of 0 accesses in the past day and millions of writes. Patch attached, Bcc'ed to openafs-bugs. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rainer Toebbicke European Laboratory for Particle Physics(CERN) - Geneva, Switzerland Phone: +41 22 767 8985 Fax: +41 22 767 7155 --------------040005060008020802060107 Content-Type: text/plain; name="p_vos_ext_stats" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="p_vos_ext_stats" --- openafs/src/volser/volprocs.c.o144 2006-12-19 04:40:14.000000000 +0100 +++ openafs/src/volser/volprocs.c 2007-10-02 10:16:48.000000000 +0200 @@ -2052,11 +2052,6 @@ xInfoP->accessDate = volDiskDataP->accessDate; xInfoP->updateDate = volDiskDataP->updateDate; xInfoP->backupDate = volDiskDataP->backupDate; - now = FT_ApproxTime(); - if (now - volDiskDataP->dayUseDate > OneDay) - xInfoP->dayUse = 0; - else - xInfoP->dayUse = volDiskDataP->dayUse; xInfoP->filecount = volDiskDataP->filecount; xInfoP->maxquota = volDiskDataP->maxquota; xInfoP->size = volDiskDataP->diskused; @@ -2064,8 +2059,15 @@ /* * Copy out the stat fields in a single operation. */ - memcpy((char *)&(xInfoP->stat_reads[0]), + now = FT_ApproxTime(); + if (now - volDiskDataP->dayUseDate > OneDay) { + xInfoP->dayUse = 0; + memset((char *)&(xInfoP->stat_reads[0]), 0, numStatBytes); + } else { + xInfoP->dayUse = volDiskDataP->dayUse; + memcpy((char *)&(xInfoP->stat_reads[0]), (char *)&(volDiskDataP->stat_reads[0]), numStatBytes); + } /* * We're done copying. Detach the volume and iterate (at this --------------040005060008020802060107-- From hans@MPA-Garching.MPG.DE Mon Oct 15 12:07:28 2007 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Mon, 15 Oct 2007 13:07:28 +0200 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release candidate 1 available In-Reply-To: References: Message-ID: <20071015110727.GA2423@ncq-5.MPA-Garching.MPG.DE> On Sun, Oct 14, 2007 at 10:16:07PM -0400, Derrick J Brashear wrote: > Notable changes include updates for newer Linux kernels (including=20 > 2.6.23) ... Does not compile on i386 and x86_64 with kernel 2.6.23. I think that linux-2623-support-20071004 is missing. With this patch applied I was able to compile OpenAFS and start the client on i386 and x86_64. HW --=20 Hans-Werner Paulsen hans@MPA-Garching.MPG.DE MPI f=FCr Astrophysik Tel 089-30000-2602 Karl-Schwarzschild-Str. 1 Fax 089-30000-2235=09 D-85741 Garching From Smith, Matt" --=-seEjrsiTCjZzmUl1RewV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Can anyone recommend a server-side Antivirus product that provides real-time (on write) server-side virus detection on my FS servers? My AFS servers are all Debian Etch. Thank you, -Matt Smith --=20 Matt Smith matt.smith@uconn.edu University Information Technology Services (UITS) University of Connecticut PGP Public Key: http://web.uconn.edu/dotmatt/matt.asc --=-seEjrsiTCjZzmUl1RewV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHE36mGP63pOnFJE4RAg01AKDGtpxqnZouqeQ9z8iv+opw1TjitwCaAz3M MjmiiQfh0eSXz9uOdND7TM0= =MQ+A -----END PGP SIGNATURE----- --=-seEjrsiTCjZzmUl1RewV-- From rra@stanford.edu Mon Oct 15 18:33:44 2007 From: rra@stanford.edu (Russ Allbery) Date: Mon, 15 Oct 2007 10:33:44 -0700 Subject: [OpenAFS] Server-side Antivirus In-Reply-To: <1192459942.7455.24.camel@d80h156.public.uconn.edu> (Matt Smith's message of "Mon, 15 Oct 2007 10:52:22 -0400") References: <1192459942.7455.24.camel@d80h156.public.uconn.edu> Message-ID: <87k5powadj.fsf@windlord.stanford.edu> "Smith, Matt" writes: > Can anyone recommend a server-side Antivirus product that provides > real-time (on write) server-side virus detection on my FS servers? My > AFS servers are all Debian Etch. I'm pretty sure such a beast doesn't exist. It would need to understand either the AFS protocol or the AFS on-disk format, and I would be stunned if any virus detector could handle either. -- Russ Allbery (rra@stanford.edu) From shadow@gmail.com Mon Oct 15 18:41:29 2007 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 15 Oct 2007 13:41:29 -0400 Subject: [OpenAFS] Server-side Antivirus In-Reply-To: <87k5powadj.fsf@windlord.stanford.edu> References: <1192459942.7455.24.camel@d80h156.public.uconn.edu> <87k5powadj.fsf@windlord.stanford.edu> Message-ID: ------=_Part_17292_18216661.1192470089553 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/15/07, Russ Allbery wrote: > > "Smith, Matt" writes: > > > Can anyone recommend a server-side Antivirus product that provides > > real-time (on write) server-side virus detection on my FS servers? My > > AFS servers are all Debian Etch. > > I'm pretty sure such a beast doesn't exist. It would need to understand > either the AFS protocol or the AFS on-disk format, and I would be stunned > if any virus detector could handle either. the on disk format for files in namei is simple: "just scan the files"; if you remove something you need to salvage the volume, though. ------=_Part_17292_18216661.1192470089553 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/15/07, Russ Allbery <rra@stanford.edu> wrote:
"Smith, Matt" <matt.smith@uconn.edu> writes:

> Can anyone recommend a server-side Antivirus product that provides
> real-time (on write) server-side virus detection on my FS servers?  My
> AFS servers are all Debian Etch.

I'm pretty sure such a beast doesn't exist.  It would need to understand
either the AFS protocol or the AFS on-disk format, and I would be stunned
if any virus detector could handle either.

the on disk format for files in namei is simple: "just scan the files"; if you remove something you need to salvage the volume, though.




------=_Part_17292_18216661.1192470089553-- From Smith, Matt" References: <1192459942.7455.24.camel@d80h156.public.uconn.edu> Message-ID: <1192532929.8190.4.camel@d80h156.public.uconn.edu> --=-7Ef6sHUV3Pa+rZanlrcm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thank you for the responses. I was guessing that there were not many options for AFS-aware AV products. So, let me ask then about best practice. What do you all do to keep viruses out of cell? * Assume all accessing workstations have up-to-date AV ? * Some network layer AV/IDS ? I'm guessing none of these are AFS aware either. * Scheduled scans of the entire AFS space ? * Carry a lucky 4-leaf clover? Thank you, -Matt On Mon, 2007-10-15 at 10:52 -0400, Smith, Matt wrote: > Can anyone recommend a server-side Antivirus product that provides > real-time (on write) server-side virus detection on my FS servers? My > AFS servers are all Debian Etch. >=20 > Thank you, > -Matt Smith >=20 --=20 Matt Smith matt.smith@uconn.edu University Information Technology Services (UITS) University of Connecticut PGP Public Key: http://web.uconn.edu/dotmatt/matt.asc --=-7Ef6sHUV3Pa+rZanlrcm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHFJvBGP63pOnFJE4RAu48AJ4tihUXvFKGXnbwJDrvt2Q6MV30AwCgkWvo E5dLDLvI/tPuebaUr1e94zs= =KMYw -----END PGP SIGNATURE----- --=-7Ef6sHUV3Pa+rZanlrcm-- From sdevine@msu.edu Tue Oct 16 13:18:26 2007 From: sdevine@msu.edu (Steve Devine) Date: Tue, 16 Oct 2007 08:18:26 -0400 Subject: [OpenAFS] Server-side Antivirus In-Reply-To: <1192532929.8190.4.camel@d80h156.public.uconn.edu> References: <1192459942.7455.24.camel@d80h156.public.uconn.edu> <1192532929.8190.4.camel@d80h156.public.uconn.edu> Message-ID: <4714AC12.1060506@msu.edu> Smith, Matt wrote: > Thank you for the responses. I was guessing that there were not many > options for AFS-aware AV products. So, let me ask then about best > practice. What do you all do to keep viruses out of cell? > > * Assume all accessing workstations have up-to-date AV ? > * Some network layer AV/IDS ? I'm guessing none of these are AFS aware > either. > * Scheduled scans of the entire AFS space ? > * Carry a lucky 4-leaf clover? > > Thank you, > -Matt > > On Mon, 2007-10-15 at 10:52 -0400, Smith, Matt wrote: > >> Can anyone recommend a server-side Antivirus product that provides >> real-time (on write) server-side virus detection on my FS servers? My >> AFS servers are all Debian Etch. >> >> Thank you, >> -Matt Smith >> >> Just my 2 cents: Afs is a filesystem. Its core responsibility is to store and protect files. All I want from AFS is file integrity. So a file I copied into AFS 3 years ago should be the exact same file today. Virus's and all. Virus scanning is someone / something else's responsibility, not AFS's. /sd -- Steve Devine Network Storage and Printing Academic Computing & Network Services Michigan State University 506 Computer Center East Lansing, MI 48824-1042 1-517-432-7327 Baseball is ninety percent mental; the other half is physical. - Yogi Berra From tdamato@odu.edu Tue Oct 16 15:05:35 2007 From: tdamato@odu.edu (Tony D'Amato) Date: Tue, 16 Oct 2007 10:05:35 -0400 Subject: [OpenAFS] openafs 1.4.5-pre1 on solaris 10 after patch 120012-14 Message-ID: <1192543534.2354.3.camel@redstripe> I built and installed OpenAFS 1.4.5-pre1 on a Solaris 10 x86 machine after installing patch 120012-14, which caused 1.4.4 to break w/ kernel panics. I'm building 1.4.5pre2 right now on it. So far so good... -- Tony D'Amato Senior UNIX Systems Administrator Systems Support Group, OCCS Old Dominion University From daleg@umbc.edu Tue Oct 16 16:46:32 2007 From: daleg@umbc.edu (Dale Ghent) Date: Tue, 16 Oct 2007 11:46:32 -0400 Subject: [OpenAFS] openafs 1.4.5-pre1 on solaris 10 after patch 120012-14 In-Reply-To: <1192543534.2354.3.camel@redstripe> References: <1192543534.2354.3.camel@redstripe> Message-ID: On Oct 16, 2007, at 10:05 AM, Tony D'Amato wrote: > I built and installed OpenAFS 1.4.5-pre1 on a Solaris 10 x86 machine > after installing > patch 120012-14, which caused 1.4.4 to break w/ kernel panics. I'm > building 1.4.5pre2 > right now on it. So far so good... Cool. Be sure to let us know if 1.4.5pre* fails on the system, complete with panic string output if possible. /dale -- Dale Ghent Specialist, Storage and UNIX Systems UMBC - Office of Information Technology ECS 201 - x51705 From tdamato@odu.edu Tue Oct 16 18:49:05 2007 From: tdamato@odu.edu (Tony D'Amato) Date: Tue, 16 Oct 2007 13:49:05 -0400 Subject: [OpenAFS] openafs 1.4.5-pre1 on solaris 10 after patch 120012-14 In-Reply-To: References: <1192543534.2354.3.camel@redstripe> Message-ID: <1192556945.2449.7.camel@redstripe> On Tue, 2007-10-16 at 11:46, Dale Ghent wrote: > On Oct 16, 2007, at 10:05 AM, Tony D'Amato wrote: > > > I built and installed OpenAFS 1.4.5-pre1 on a Solaris 10 x86 machine > > after installing > > patch 120012-14, which caused 1.4.4 to break w/ kernel panics. I'm > > building 1.4.5pre2 > > right now on it. So far so good... > > Cool. Be sure to let us know if 1.4.5pre* fails on the system, > complete with panic string output if possible. Done... I'm running OpenAFS 1.4.5pre2 on the Solaris box now. I'm also getting ready to compile 1.4.5pre2 it on a RHEL5 test box (my laptop *grin*)... I'll keep y'all posted... Thanks! -- Tony D'Amato Senior UNIX Systems Administrator Systems Support Group, OCCS Old Dominion University From deengert@anl.gov Tue Oct 16 18:53:20 2007 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 16 Oct 2007 12:53:20 -0500 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release candidate 2 available In-Reply-To: References: Message-ID: <4714FA90.6090303@anl.gov> Derrick J Brashear wrote: > The OpenAFS Gatekeepers announce the availability of the second release > candidate for OpenAFS version 1.4.5. > Source files and available binaries can be accessed via the web at: > > http://www.openafs.org/release/openafs-1.4.5pre2.html Built and runs Solaris 10 sun4x_510. Has the issue with the translator as reported yesterday. http://rt.central.org/rt/index.html?q=74448 > > or via AFS at: > > UNIX: /afs/grand.central.org/software/openafs/candidate/1.4.5pre2/ > UNC: \\afs\grand.central.org\software\openafs\candidate\1.4.5pre\ > > > Notable changes include updates for newer Linux kernels (including > 2.6.23), Solaris 10 Update 4 client support, and updated MacOS X > support, as well as improvements to the host tracking in the fileserver. > > Changes since the previous candidate including additional tests needed > for newer Linux kernels and a MacOS 10.4 "dropbox directory" support > update in the client. > > Please assist the gatekeepers by deploying this release and providing > positive or negative feedback. Bug reports should be filed to > openafs-bugs@openafs.org . Reports of success should be sent to > openafs-info@openafs.org . > > Derrick Brashear > for the OpenAFS Gatekeepers > _______________________________________________ > OpenAFS-announce mailing list > OpenAFS-announce@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-announce > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From mizmoose@gmail.com Tue Oct 16 21:20:18 2007 From: mizmoose@gmail.com (Esther Filderman) Date: Tue, 16 Oct 2007 16:20:18 -0400 Subject: [OpenAFS] Can your AFS site be used in PR? Message-ID: Folks, I'm developing a pamphlet that can be used to publicize OpenAFS at various events and such. I'd like to place on it a list of sites that use OpenAFS. Can I use your site? If so, please tell me the proper name of your site, and what you use it for, and how big (servers & data amount) your cell is. Special request for non-University academia, small businesses and unique uses, although anyone is MORE than welcome to respond! Thanks, Moose From jason@rampaginggeek.com Wed Oct 17 02:33:18 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Tue, 16 Oct 2007 21:33:18 -0400 Subject: [OpenAFS] 1.4.5rc1 client works on ppc mac Message-ID: <4715665E.906@rampaginggeek.com> Hi, 1.4.5rc1 has been working well on my powerbook g4 for the past couple of days. Jason From rra@stanford.edu Wed Oct 17 06:46:54 2007 From: rra@stanford.edu (Russ Allbery) Date: Tue, 16 Oct 2007 22:46:54 -0700 Subject: [OpenAFS] 1.4.5pre2 packages uploaded to Debian unstable Message-ID: <874pgqjnsh.fsf@windlord.stanford.edu> I've uploaded packages of 1.4.5pre2 to Debian unstable. That should fix several outstanding bugs reported in Debian. -- Russ Allbery (rra@stanford.edu) From bracco@frascati.enea.it Wed Oct 17 07:36:27 2007 From: bracco@frascati.enea.it (Giovanni Bracco) Date: Wed, 17 Oct 2007 08:36:27 +0200 Subject: [OpenAFS] Publishing a FUSE file system over OpenAFS In-Reply-To: <4712902F.1030302@communitymesh.com> References: <4712902F.1030302@communitymesh.com> Message-ID: <200710170836.27663.bracco@frascati.enea.it> Have you see the thread of the previous posting to openafs-info@openafs.org? http://www.openafs.org/pipermail/openafs-info/2007-January/024971.html Giovanni On Sunday 14 October 2007 23:54, Anthony Wright wrote: > I've been interested in using OpenAFS as an alternative to NFS for a > while now, and most of the arguments in it's favour seem fairly > compelling, but i'm struggling with one issue. > > I'm in the process of building a system which will use a FUSE File > System which I then want to publish over a network. I can clearly > understand how to do this with NFS, but from my (limited) knowledge, > OpenAFS seems to be much more tightly bound to the underlying file > system than NFS, and I can't see how I produce a FUSE file system, and > then access that file system through an OpenAFS client. > > Is this something that can be done under OpenAFS and if so how? If not > is there an OpenAFS API similar in concept to FUSE that would allow a > user mode program to publish a file system over OpenAFS? > > If the answer to these two questions is no, does this mean I've found > out a way in which NFS is better than OpenAFS? ;-) > > Many thanks, > > Tony Wright. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Giovanni Bracco ENEA FIM (Servizio Informatica e Reti) Via E. Fermi 45 I-00044 Frascati (Roma) Italy phone 00-39-06-9400-5597 FAX 00-39-06-9400-5735 E-mail bracco@frascati.enea.it WWW http://fusfis.frascati.enea.it/~bracco From shadow@gmail.com Wed Oct 17 20:01:55 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 17 Oct 2007 15:01:55 -0400 Subject: [OpenAFS] Publishing a FUSE file system over OpenAFS In-Reply-To: <200710170836.27663.bracco@frascati.enea.it> References: <4712902F.1030302@communitymesh.com> <200710170836.27663.bracco@frascati.enea.it> Message-ID: ------=_Part_24368_2859739.1192647715759 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/17/07, Giovanni Bracco wrote: > > Have you see the thread of the previous posting to > openafs-info@openafs.org? > http://www.openafs.org/pipermail/openafs-info/2007-January/024971.html > Giovanni To be fair, instead of the minimal FUSE filesystem redirector, Arla uses its own (nnpfs) But it's the same idea. ------=_Part_24368_2859739.1192647715759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/17/07, Giovanni Bracco <bracco@frascati.enea.it> wrote:
Have you see the thread of the previous posting to openafs-info@openafs.org?
http://www.openafs.org/pipermail/openafs-info/2007-January/024971.html
Giovanni


To be fair, instead of the minimal FUSE filesystem redirector, Arla uses its own (nnpfs)

But it's the same idea.
 


------=_Part_24368_2859739.1192647715759-- From scs@umich.edu Wed Oct 17 20:28:12 2007 From: scs@umich.edu (Steve Simmons) Date: Wed, 17 Oct 2007 15:28:12 -0400 Subject: [OpenAFS] File server not parallelized on restart? Message-ID: <204D4EC3-2633-42FC-B991-82816093BE66@umich.edu> We had an AFS hang today (more detail after we complete the post- mortem). It required doing a hard reboot on the server. On reboot, it began salvaging the two partitions in parallel as normal. Wwhen the salvages completed, it started attaching the partitions sequentially. Here are the relevant times and events from the log. This last 4 in the sequence look funny to me: 13:30:40 /vicepa salvage started 13:30:40 /vicepb salvage started 14:23:07 /vicepb salvage completed 14:35:59 /vicepa salvage completed 14:36:01 fs starts attaching /vicepb volumes 14:50:16 fs finishes attaching /vicepb volumes 14:50:16 fs starts attaching /vicepa volumes Should it have started attaching /vicepa volumes as soon as that salvage completed, or am I laboring under a misconception here? Advance thanks, Steve From shadow@gmail.com Wed Oct 17 20:36:08 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 17 Oct 2007 15:36:08 -0400 Subject: [OpenAFS] File server not parallelized on restart? In-Reply-To: <204D4EC3-2633-42FC-B991-82816093BE66@umich.edu> References: <204D4EC3-2633-42FC-B991-82816093BE66@umich.edu> Message-ID: ------=_Part_24516_18728440.1192649768286 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/17/07, Steve Simmons wrote: > > We had an AFS hang today (more detail after we complete the post- > mortem). It required doing a hard reboot on the server. On reboot, it > began salvaging the two partitions in parallel as normal. Wwhen the > salvages completed, it started attaching the partitions sequentially. > Here are the relevant times and events from the log. This last 4 in > the sequence look funny to me: > > 13:30:40 /vicepa salvage started > 13:30:40 /vicepb salvage started > 14:23:07 /vicepb salvage completed > 14:35:59 /vicepa salvage completed > 14:36:01 fs starts attaching /vicepb volumes > 14:50:16 fs finishes attaching /vicepb volumes > 14:50:16 fs starts attaching /vicepa volumes > > Should it have started attaching /vicepa volumes as soon as that > salvage completed, or am I laboring under a misconception here? > > Advance thanks, nope, it's serial unless you have 1.5, with -vattachpar set, and will do them in reverse in some versions due to a minor bug since fixed. ------=_Part_24516_18728440.1192649768286 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/17/07, Steve Simmons <scs@umich.edu> wrote:
We had an AFS hang today (more detail after we complete the post-
mortem). It required doing a hard reboot on the server. On reboot, it
began salvaging the two partitions in parallel as normal. Wwhen the
salvages completed, it started attaching the partitions sequentially.
Here are the relevant times and events from the log. This last 4 in
the sequence look funny to me:

13:30:40 /vicepa salvage started
13:30:40 /vicepb salvage started
14:23:07 /vicepb salvage completed
14:35:59 /vicepa salvage completed
14:36:01 fs starts attaching /vicepb volumes
14:50:16 fs finishes attaching /vicepb volumes
14:50:16 fs starts attaching /vicepa volumes

Should it have started attaching /vicepa volumes as soon as that
salvage completed, or am I laboring under a misconception here?

Advance thanks,

nope, it's serial unless you have 1.5, with -vattachpar set, and will do them in reverse in some versions due to a minor bug since fixed.
 


------=_Part_24516_18728440.1192649768286-- From anthony@communitymesh.com Wed Oct 17 23:07:26 2007 From: anthony@communitymesh.com (Anthony Wright) Date: Wed, 17 Oct 2007 23:07:26 +0100 Subject: [OpenAFS] Publishing a FUSE file system over OpenAFS In-Reply-To: <200710170836.27663.bracco@frascati.enea.it> References: <4712902F.1030302@communitymesh.com> <200710170836.27663.bracco@frascati.enea.it> Message-ID: <4716879E.4010807@communitymesh.com> I had a look at the thread, but unless I'm mistaken it's talking about using FUSE to publish an AFS filesystem, rather than using AFS to publish a FUSE filesystem. Giovanni Bracco wrote: > Have you see the thread of the previous posting to openafs-info@openafs.org? > http://www.openafs.org/pipermail/openafs-info/2007-January/024971.html > Giovanni > On Sunday 14 October 2007 23:54, Anthony Wright wrote: > >> I've been interested in using OpenAFS as an alternative to NFS for a >> while now, and most of the arguments in it's favour seem fairly >> compelling, but i'm struggling with one issue. >> >> I'm in the process of building a system which will use a FUSE File >> System which I then want to publish over a network. I can clearly >> understand how to do this with NFS, but from my (limited) knowledge, >> OpenAFS seems to be much more tightly bound to the underlying file >> system than NFS, and I can't see how I produce a FUSE file system, and >> then access that file system through an OpenAFS client. >> >> Is this something that can be done under OpenAFS and if so how? If not >> is there an OpenAFS API similar in concept to FUSE that would allow a >> user mode program to publish a file system over OpenAFS? >> >> If the answer to these two questions is no, does this mean I've found >> out a way in which NFS is better than OpenAFS? ;-) >> >> Many thanks, >> >> Tony Wright. >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > From shadow@gmail.com Thu Oct 18 03:14:27 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 17 Oct 2007 22:14:27 -0400 Subject: [OpenAFS] Publishing a FUSE file system over OpenAFS In-Reply-To: <4716879E.4010807@communitymesh.com> References: <4712902F.1030302@communitymesh.com> <200710170836.27663.bracco@frascati.enea.it> <4716879E.4010807@communitymesh.com> Message-ID: ------=_Part_25747_21612367.1192673667525 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline You want hostafsd. More work is forthcoming on it. Of course, publishing a FUSE filesystem, why bother? You don't need to involve the kernel VFS (the part that FUSE does) because... you're publishing it via the network to AFS clients anyway. On 10/17/07, Anthony Wright wrote: > > I had a look at the thread, but unless I'm mistaken it's talking about > using FUSE to publish an AFS filesystem, rather than using AFS to > publish a FUSE filesystem. > > Giovanni Bracco wrote: > > Have you see the thread of the previous posting to > openafs-info@openafs.org? > > http://www.openafs.org/pipermail/openafs-info/2007-January/024971.html > > Giovanni > > On Sunday 14 October 2007 23:54, Anthony Wright wrote: > > > >> I've been interested in using OpenAFS as an alternative to NFS for a > >> while now, and most of the arguments in it's favour seem fairly > >> compelling, but i'm struggling with one issue. > >> > >> I'm in the process of building a system which will use a FUSE File > >> System which I then want to publish over a network. I can clearly > >> understand how to do this with NFS, but from my (limited) knowledge, > >> OpenAFS seems to be much more tightly bound to the underlying file > >> system than NFS, and I can't see how I produce a FUSE file system, and > >> then access that file system through an OpenAFS client. > >> > >> Is this something that can be done under OpenAFS and if so how? If not > >> is there an OpenAFS API similar in concept to FUSE that would allow a > >> user mode program to publish a file system over OpenAFS? > >> > >> If the answer to these two questions is no, does this mean I've found > >> out a way in which NFS is better than OpenAFS? ;-) > >> > >> Many thanks, > >> > >> Tony Wright. > >> _______________________________________________ > >> OpenAFS-info mailing list > >> OpenAFS-info@openafs.org > >> https://lists.openafs.org/mailman/listinfo/openafs-info > >> > > > > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > ------=_Part_25747_21612367.1192673667525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline You want hostafsd. More work is forthcoming on it. Of course, publishing a FUSE filesystem, why bother? You don't need to involve the kernel VFS (the part that FUSE does) because... you're publishing it via the network to AFS clients anyway.


On 10/17/07, Anthony Wright <anthony@communitymesh.com> wrote:
I had a look at the thread, but unless I'm mistaken it's talking about
using FUSE to publish an AFS filesystem, rather than using AFS to
publish a FUSE filesystem.

Giovanni Bracco wrote:
> Have you see the thread of the previous posting to openafs-info@openafs.org?
> http://www.openafs.org/pipermail/openafs-info/2007-January/024971.html
> Giovanni
> On Sunday 14 October 2007 23:54, Anthony Wright wrote:
>
>> I've been interested in using OpenAFS as an alternative to NFS for a
>> while now, and most of the arguments in it's favour seem fairly
>> compelling, but i'm struggling with one issue.
>>
>> I'm in the process of building a system which will use a FUSE File
>> System which I then want to publish over a  network. I can  clearly
>> understand how to do this with NFS, but  from my (limited) knowledge,
>> OpenAFS seems to be much more tightly bound to the underlying file
>> system than NFS, and I can't see how I produce a FUSE file system, and
>> then access that file system through an OpenAFS client.
>>
>> Is this something that can be done under OpenAFS and if so how? If not
>> is there an OpenAFS API similar in concept to FUSE that would allow a
>> user mode program to publish a file system over OpenAFS?
>>
>> If the answer to these two questions is no, does this mean I've found
>> out a way in which NFS is better than OpenAFS? ;-)
>>
>> Many thanks,
>>
>> Tony Wright.
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
>
>

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

------=_Part_25747_21612367.1192673667525-- From anthony@communitymesh.com Thu Oct 18 07:29:09 2007 From: anthony@communitymesh.com (Anthony Wright) Date: Thu, 18 Oct 2007 07:29:09 +0100 Subject: [OpenAFS] Publishing a FUSE file system over OpenAFS In-Reply-To: References: <4712902F.1030302@communitymesh.com> <200710170836.27663.bracco@frascati.enea.it> <4716879E.4010807@communitymesh.com> Message-ID: <4716FD35.3060405@communitymesh.com> I realise that using FUSE would add a whole layer of inefficiency but it's a clean, well defined API to write to. My other thought was whether the OpenAFS server includes an API which is similar in concept to FUSE which I could use to publish my filesystem directly to OpenAFS, avoiding FUSE & kernel VFS altogether. It would mean that I could publish the file system over OpenAFS, but not over other networked file systems, for example Samba. However, if the API wasn't too complex, I couldn't see that being a big problem as I could publish to both APIs if I needed. Does OpenAFS have such an API? Derrick Brashear wrote: > You want hostafsd. More work is forthcoming on it. Of course, > publishing a FUSE filesystem, why bother? You don't need to involve > the kernel VFS (the part that FUSE does) because... you're publishing > it via the network to AFS clients anyway. > > > On 10/17/07, *Anthony Wright* > wrote: > > I had a look at the thread, but unless I'm mistaken it's talking about > using FUSE to publish an AFS filesystem, rather than using AFS to > publish a FUSE filesystem. > > Giovanni Bracco wrote: > > Have you see the thread of the previous posting to > openafs-info@openafs.org ? > > > http://www.openafs.org/pipermail/openafs-info/2007-January/024971.html > > > Giovanni > > On Sunday 14 October 2007 23:54, Anthony Wright wrote: > > > >> I've been interested in using OpenAFS as an alternative to NFS > for a > >> while now, and most of the arguments in it's favour seem fairly > >> compelling, but i'm struggling with one issue. > >> > >> I'm in the process of building a system which will use a FUSE File > >> System which I then want to publish over a network. I > can clearly > >> understand how to do this with NFS, but from my (limited) > knowledge, > >> OpenAFS seems to be much more tightly bound to the underlying file > >> system than NFS, and I can't see how I produce a FUSE file > system, and > >> then access that file system through an OpenAFS client. > >> > >> Is this something that can be done under OpenAFS and if so how? > If not > >> is there an OpenAFS API similar in concept to FUSE that would > allow a > >> user mode program to publish a file system over OpenAFS? > >> > >> If the answer to these two questions is no, does this mean I've > found > >> out a way in which NFS is better than OpenAFS? ;-) > >> > >> Many thanks, > >> > >> Tony Wright. > >> _______________________________________________ > >> OpenAFS-info mailing list > >> OpenAFS-info@openafs.org > >> https://lists.openafs.org/mailman/listinfo/openafs-info > >> > > > > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > > From jaltman@secure-endpoints.com Thu Oct 18 07:43:55 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 18 Oct 2007 02:43:55 -0400 Subject: [OpenAFS] Publishing a FUSE file system over OpenAFS In-Reply-To: <4716FD35.3060405@communitymesh.com> References: <4712902F.1030302@communitymesh.com> <200710170836.27663.bracco@frascati.enea.it> <4716879E.4010807@communitymesh.com> <4716FD35.3060405@communitymesh.com> Message-ID: <471700AB.3050601@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms050601010702030204040201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anthony Wright wrote: > I realise that using FUSE would add a whole layer of inefficiency but > it's a clean, well defined API to write to. My other thought was whether > the OpenAFS server includes an API which is similar in concept to FUSE > which I could use to publish my filesystem directly to OpenAFS, avoiding > FUSE & kernel VFS altogether. It would mean that I could publish the > file system over OpenAFS, but not over other networked file systems, for > example Samba. However, if the API wasn't too complex, I couldn't see > that being a big problem as I could publish to both APIs if I needed. > Does OpenAFS have such an API? OpenAFS does not have such an API. OpenAFS does not serve files the way most file systems do. All files in AFS are currently stored in a portable volume format that permits the data to be easily migrated and replicated between file servers running on heterogeneous architectures with otherwise incompatible local file storage. Data stored in AFS can only be accessed through an AFS client. Even on the machine on which the data is physically located. The hostafsd project that we have mentioned to you is a first attempt at permitting the contents of the local file system to be served to AFS clients without requiring that the data be stored in AFS volumes. While this approach will permit AFS clients to access data stored on arbitrary local file systems what is lost are the AFS volume management capabilities including AFS replication. Eventually we hope to have a multi-backend file server implementation that will permit a mixture of AFS volume based backends (inode and namei) and local file system export (hostafs) to exist in the same file server at the same time. This would permit easy transitions into and out of AFS. Once this architecture is in place you could write just about any backend you wish provided that the underlying file system could satisfy the requirements of AFS. The most important of which is the ability to notify the file server when the contents or metadata of a directory or file have changed. There are no estimates for when the multi-backend file server will be completed. Jeffrey Altman --------------ms050601010702030204040201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMTgwNjQzNTVaMCMGCSqGSIb3DQEJBDEWBBR3nRs6 v86qiNOBpki1R3Yo8PH3ADBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAiFpdH8FVaN2hQU/DDbAaiizZb1HwATPh6qfq0Pwzu1isKkw90MUq fa8E/DzzkeJkkb1JCF3RJG+cvaDrb0xfeCWIxkeiz0sfELa24PsIY+iLxza/6i+7E3VlFX02 10NCCohGKjxg4huH27iddzXjKCn++6L/Mc9iBC2RppkGve/0gZYY3DZNj64FpkJ45ZX+Hp63 MSVMNnwtnkA5cC2IObOwxDkc7rqATQ0SA05So/jthVI57bQNd/efk3Ac4pCTQql4sXkQDWyN A6Xg7efdKTgWSu4kHrkFCg5kS3AAwu7cfNYRzRMlnMkyuL5eg4mp4aiLe4F8XTFfJX73YAlq ygAAAAAAAA== --------------ms050601010702030204040201-- From tkeiser@gmail.com Thu Oct 18 13:41:00 2007 From: tkeiser@gmail.com (Tom Keiser) Date: Thu, 18 Oct 2007 08:41:00 -0400 Subject: [OpenAFS] File server not parallelized on restart? In-Reply-To: References: <204D4EC3-2633-42FC-B991-82816093BE66@umich.edu> Message-ID: <217964d60710180541q3e34f3cja9b2419cc2c38283@mail.gmail.com> On 10/17/07, Derrick Brashear wrote: > > > On 10/17/07, Steve Simmons wrote: > > We had an AFS hang today (more detail after we complete the post- > > mortem). It required doing a hard reboot on the server. On reboot, it > > began salvaging the two partitions in parallel as normal. Wwhen the > > salvages completed, it started attaching the partitions sequentially. > > Here are the relevant times and events from the log. This last 4 in > > the sequence look funny to me: > > > > 13:30:40 /vicepa salvage started > > 13:30:40 /vicepb salvage started > > 14:23:07 /vicepb salvage completed > > 14:35:59 /vicepa salvage completed > > 14:36:01 fs starts attaching /vicepb volumes > > 14:50:16 fs finishes attaching /vicepb volumes > > 14:50:16 fs starts attaching /vicepa volumes > > > > Should it have started attaching /vicepa volumes as soon as that > > salvage completed, or am I laboring under a misconception here? > > The mode of operation is basically whole-partition-salvager XOR fileserver+volserver. In order to guarantee mutually exclusive access, the bosserver won't start the fileserver and volserver until the salvager has exited. > > Advance thanks, > > nope, it's serial unless you have 1.5, with -vattachpar set, and will do > them in reverse in some versions due to a minor bug since fixed. > Parallel volume attachment support ships with 1.3.83 and above. Parallel shutdown requires DAFS. As Derrick mentioned, -vattachpar controls parallelization of startup and shutdown in the volume package. Unless set explicitly, -vattachpar has a value of 1, thus providing the classic single threaded behavior by default. The single-threaded partition attachment ordering fix was committed in time for 1.4.4. Regards, -Tom From tjobrien@hiwaay.net Thu Oct 18 20:26:54 2007 From: tjobrien@hiwaay.net (Tim OBrien) Date: Thu, 18 Oct 2007 14:26:54 -0500 (CDT) Subject: [OpenAFS] AFS always readonly? Message-ID: <1192735614.4717b37ee20e9@webmail.hiwaay.net> I have AFS for Win32 set up between two machines at different sites. Both have AFS servers set up, and they're both in the same cell. The machine in my office has a file on it, and I can get to the file using the AFS client on that machine. However, from the other machine, I can't create a mountpoint in afs or do much of anything, since it states that /afs is mounted read only. I used the same credentials I used on the server (where the client gets r/w access), and the client software took the credentials and said they were valid, etc.. I admit to being a newbie, and I've read a lot to try and help myself... Unfortunately I can't seem to get past this read only issue. Could someone point me in the right direction? Also, does anyone know of a simple tutorial that illustrates from start to finish, for newbies, how to set up a cell, share files, and work with the files from other machines? Any help would be greatly appreciated. Thanks, -- Tim O'Brien -- From allbery@ece.cmu.edu Thu Oct 18 22:20:08 2007 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu, 18 Oct 2007 17:20:08 -0400 Subject: [OpenAFS] AFS always readonly? In-Reply-To: <1192735614.4717b37ee20e9@webmail.hiwaay.net> References: <1192735614.4717b37ee20e9@webmail.hiwaay.net> Message-ID: <4C243104-D638-4523-8032-5A5DABA7776A@ece.cmu.edu> On Oct 18, 2007, at 15:26 , Tim OBrien wrote: > machine. However, from the other machine, I can't create a > mountpoint in afs or > do much of anything, since it states that /afs is mounted read > only. I used the Normally if a read only replica exists it will be mounted by preference. The usefulness of r/o replicas is in fact dependent on / afs mounting read-only by default. Usually one creates an explicit read-write mountpoint for the cell (/ afs/.cell vs. /afs/cell) while the initial root.cell and root.afs are still not replicated. Once you have the latter, you can always create a read-write mount for root.afs or other volumes. (-dynroot should do this automatically) If you have inadvertently created a cell without a forced r/w mount in your root.afs, there are two ways to fix it: - create such r/w mount in some other cell that has an r/w mount and knows how to reach yours (requires you to auth to *your* cell, so crossrealm/cross-cell auth is not necessary, but you may need to insure that using your cell's Kerberos tickets won't cripple your access to the machine in the foreign realm/cell) - bring up a client with -dynroot, which should get you an automatic r/w mountpoint, and fix the static mounts from there. (Several years back when a combination of a corrupted r/w site for root.afs and a pair of inexperienced admins caused our /afs to suddenly become quite empty, afs didn't have dynroot. Luckily I had a test cell running which knew how to reach the main one, so I was able to repopulate root.afs remotely. These days -dynroot is almost certainly the best way to go for this.) As for the difference between the two machines: you probably haven't restarted the client on the first machine yet, so its initial read- write mount of /afs is still intact. You should probably use that to make sure the /afs/.cell forced read-write mount of root.cell is present, and rerelease. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jaltman@secure-endpoints.com Thu Oct 18 22:30:18 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 18 Oct 2007 17:30:18 -0400 Subject: [OpenAFS] AFS always readonly? In-Reply-To: <4C243104-D638-4523-8032-5A5DABA7776A@ece.cmu.edu> References: <1192735614.4717b37ee20e9@webmail.hiwaay.net> <4C243104-D638-4523-8032-5A5DABA7776A@ece.cmu.edu> Message-ID: <4717D06A.6090000@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms010207060709060803070300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brandon S. Allbery KF8NH wrote: > If you have inadvertently created a cell without a forced r/w mount in > your root.afs, there are two ways to fix it: If you are using the Windows AFS client using Freelance mode \\AFS\cellname%volumename\ gives you a read-write path to the volume. \\AFS\cellname#volumename\ gives you the normal path to the volume. --------------ms010207060709060803070300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMTgyMTMwMThaMCMGCSqGSIb3DQEJBDEWBBTcq4uR Mdx4ix6TBvlw9qWoEJ/WADBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAgGq4nIXARppUM4jAWZgc1b7RFVK/bAWSfMJF1e11kZArbRUw237A ycyMuEGHV31O+3zWXSBst0tbMRgsW9KH3Tq0ztzXgdhNJ05hfplAyAjviKxr/yc7qoQB6YlP hazNy0wO2AZcRisvzZrLDShRM4aKUYr+rg4Fxv3VmOhBlhbrUCuT0AIJshmiXtfIbK4VyqKV BOgNmDHQ7kYcDOb2aVkR8x4nLSvDIE7foolQ9u5I9xn025hPZ2m4zzVcv/xM07jx4OutF5ZN Cnd7/PV7i2jzsLXDG4//HaCVorB2k5qhiKRZuX1BkSh37NSUgdGhOGZL/PJViJyPh4IOFjjV +QAAAAAAAA== --------------ms010207060709060803070300-- From deengert@anl.gov Thu Oct 18 22:59:43 2007 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 18 Oct 2007 16:59:43 -0500 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release candidate 3 available In-Reply-To: References: Message-ID: <4717D74F.9010703@anl.gov> Derrick J Brashear wrote: > The OpenAFS Gatekeepers announce the availability of the third release > candidate for OpenAFS version 1.4.5. > Source files and available binaries can be accessed via the web at: > > http://www.openafs.org/release/openafs-1.4.5pre3.html OK, built and running on sun4x_510 (u4) with no patches. I will try translator and sun4x_59 and sun4x_58 tomorrow. > > or via AFS at: > > UNIX: /afs/grand.central.org/software/openafs/candidate/1.4.5pre3/ > UNC: \\afs\grand.central.org\software\openafs\candidate\1.4.5pre3\ > > > Notable changes include updates for newer Linux kernels (including > 2.6.23), Solaris 10 Update 4 client support, and updated MacOS X > support, as well as improvements to the host tracking in the fileserver. > > Changes since the previous candidate include nfs translator bugfixes, > Linux packaging updates, and updates for MacOS client support. > > Please assist the gatekeepers by deploying this release and providing > positive or negative feedback. Bug reports should be filed to > openafs-bugs@openafs.org . Reports of success should be sent to > openafs-info@openafs.org . > > Derrick Brashear > for the OpenAFS Gatekeepers > _______________________________________________ > OpenAFS-announce mailing list > OpenAFS-announce@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-announce > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From sxw@inf.ed.ac.uk Fri Oct 19 16:44:09 2007 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Fri, 19 Oct 2007 16:44:09 +0100 Subject: [OpenAFS] Quick Start Guide updated for Kerberos v5 Message-ID: I've just made an HTML version of the current OpenAFS Quick Start Guide for Unix available at http://homepages.inf.ed.ac.uk/sxw/OpenAFSQuickStart/book1.html This includes a load of changes that were made a few months ago to update the guide so that it describes the process of setting up a cell using Kerberos 5, rather than kaserver. As the main author of those modifications, I'd welcome feedback about those instructions. Cheers, Simon. From jason@rampaginggeek.com Sat Oct 20 17:22:28 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Sat, 20 Oct 2007 12:22:28 -0400 Subject: [OpenAFS] Quick Start Guide updated for Kerberos v5 In-Reply-To: References: Message-ID: <471A2B44.1010900@rampaginggeek.com> Simon Wilkinson wrote: > I've just made an HTML version of the current OpenAFS Quick Start > Guide for Unix available at > http://homepages.inf.ed.ac.uk/sxw/OpenAFSQuickStart/book1.html > > This includes a load of changes that were made a few months ago to > update the guide so that it describes the process of setting up a cell > using Kerberos 5, rather than kaserver. As the main author of those > modifications, I'd welcome feedback about those instructions. Hi Simon, Thanks for doing this. I've done a quick read of your document. Here are my notes: chapter1: * about upgrading OS: **Should the namei fileserver be mentioned? Is namei the recommended way? chapter 2: * getting started on solaris: ** it still mentions copying files from cd-rom (grep for "CD-ROM") **only mentions solaris 7, it should mention 8, 9 & 10/opensolaris or just say 7 & later versions ** about fsck: does solaris use inode, namei or both? Is clarification needed? (I could only review solaris & linux. I don't know AIX, HPUX, or IRIX) "The entry for AFS server processes, called either *afs* or *afs//cell/*. No user logs in under this identity, but it is used to encrypt the server tickets that granted to AFS clients for presentation to server processes during mutual authentication." should that be "...that are granted to AFS clients..."? I read up through "Initializing the Protection Database". I'll finish reading it later. Jason From shadow@gmail.com Tue Oct 23 01:27:20 2007 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 22 Oct 2007 20:27:20 -0400 Subject: [OpenAFS] Quick Start Guide updated for Kerberos v5 In-Reply-To: <471A2B44.1010900@rampaginggeek.com> References: <471A2B44.1010900@rampaginggeek.com> Message-ID: ------=_Part_11881_10870936.1193099240567 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/20/07, Jason Edgecombe wrote: > > Simon Wilkinson wrote: > > I've just made an HTML version of the current OpenAFS Quick Start > > Guide for Unix available at > > http://homepages.inf.ed.ac.uk/sxw/OpenAFSQuickStart/book1.html > > > > This includes a load of changes that were made a few months ago to > > update the guide so that it describes the process of setting up a cell > > using Kerberos 5, rather than kaserver. As the main author of those > > modifications, I'd welcome feedback about those instructions. > Hi Simon, > > Thanks for doing this. I've done a quick read of your document. Here are > my notes: (a bunch of things which have nothing to do with Kerberos 5) Erm? ------=_Part_11881_10870936.1193099240567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/20/07, Jason Edgecombe <jason@rampaginggeek.com> wrote:
Simon Wilkinson wrote:
> I've just made an HTML version of the current OpenAFS Quick Start
> Guide for Unix available at
> http://homepages.inf.ed.ac.uk/sxw/OpenAFSQuickStart/book1.html
>
> This includes a load of changes that were made a few months ago to
> update the guide so that it describes the process of setting up a cell
> using Kerberos 5, rather than kaserver. As the main author of those
> modifications, I'd welcome feedback about those instructions.
Hi Simon,

Thanks for doing this. I've done a quick read of your document. Here are
my notes:

(a bunch of things which have nothing to do with Kerberos 5)
 
Erm?



------=_Part_11881_10870936.1193099240567-- From jason@rampaginggeek.com Tue Oct 23 03:03:07 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Mon, 22 Oct 2007 22:03:07 -0400 Subject: [OpenAFS] Quick Start Guide updated for Kerberos v5 In-Reply-To: References: <471A2B44.1010900@rampaginggeek.com> Message-ID: <471D565B.2030107@rampaginggeek.com> Derrick Brashear wrote: > > > On 10/20/07, *Jason Edgecombe* > wrote: > > Simon Wilkinson wrote: > > I've just made an HTML version of the current OpenAFS Quick Start > > Guide for Unix available at > > http://homepages.inf.ed.ac.uk/sxw/OpenAFSQuickStart/book1.html > > > > > This includes a load of changes that were made a few months ago to > > update the guide so that it describes the process of setting up > a cell > > using Kerberos 5, rather than kaserver. As the main author of those > > modifications, I'd welcome feedback about those instructions. > Hi Simon, > > Thanks for doing this. I've done a quick read of your document. > Here are > my notes: > > > (a bunch of things which have nothing to do with Kerberos 5) > > Erm? > Nothing, I guess. Just trying to be helpful. :P Jason From hanke@rzg.mpg.de Tue Oct 23 08:20:45 2007 From: hanke@rzg.mpg.de (Christof Hanke) Date: Tue, 23 Oct 2007 10:20:45 +0300 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release candidate 4 available In-Reply-To: References: Message-ID: <471DA0CD.8010501@rzg.mpg.de> Derrick J Brashear wrote: > The OpenAFS Gatekeepers announce the availability of the fourth release > candidate for OpenAFS version 1.4.5. > Source files and available binaries can be accessed via the web at: > > http://www.openafs.org/release/openafs-1.4.5pre4.html > > or via AFS at: > > UNIX: /afs/grand.central.org/software/openafs/candidate/1.4.5pre4/ > UNC: \\afs\grand.central.org\software\openafs\candidate\1.4.5pre4\ > Well, someone within grand.central.org forgot to release some parent-volume. Thus, at the minute the files are only available via the RW-Path within AFS at : UNIX: /afs/.grand.central.org/software/openafs/candidate/1.4.5pre4/ UNC: \\afs\.grand.central.org\software\openafs\candidate\1.4.5pre4\ T/Christof From dhk@ccre.com Tue Oct 23 21:28:32 2007 From: dhk@ccre.com (Kim Kimball) Date: Tue, 23 Oct 2007 14:28:32 -0600 Subject: [OpenAFS] AFS always readonly? In-Reply-To: <24235184.1192742743675.JavaMail.root@m11> References: <1192735614.4717b37ee20e9@webmail.hiwaay.net> <24235184.1192742743675.JavaMail.root@m11> Message-ID: <471E5970.9010900@ccre.com> You can also remove the root.afs.readonly instances, do an "fs checkv," add the "dot path" (fs mkm /afs/. root.afs -rw) and then replicate root.afs again. After that /afs/. will give RW access to all volumes mounted below /afs/. as long as they're not explicitly mounted as .readonly or .backup volumes. Kim Brandon S. Allbery KF8NH wrote: > > On Oct 18, 2007, at 15:26 , Tim OBrien wrote: > >> machine. However, from the other machine, I can't create a mountpoint >> in afs or >> do much of anything, since it states that /afs is mounted read only. >> I used the > > Normally if a read only replica exists it will be mounted by > preference. The usefulness of r/o replicas is in fact dependent on > /afs mounting read-only by default. > > Usually one creates an explicit read-write mountpoint for the cell > (/afs/.cell vs. /afs/cell) while the initial root.cell and root.afs > are still not replicated. Once you have the latter, you can always > create a read-write mount for root.afs or other volumes. (-dynroot > should do this automatically) > > If you have inadvertently created a cell without a forced r/w mount in > your root.afs, there are two ways to fix it: > > - create such r/w mount in some other cell that has an r/w mount and > knows how to reach yours (requires you to auth to *your* cell, so > crossrealm/cross-cell auth is not necessary, but you may need to > insure that using your cell's Kerberos tickets won't cripple your > access to the machine in the foreign realm/cell) > > - bring up a client with -dynroot, which should get you an automatic > r/w mountpoint, and fix the static mounts from there. > > (Several years back when a combination of a corrupted r/w site for > root.afs and a pair of inexperienced admins caused our /afs to > suddenly become quite empty, afs didn't have dynroot. Luckily I had a > test cell running which knew how to reach the main one, so I was able > to repopulate root.afs remotely. These days -dynroot is almost > certainly the best way to go for this.) > > As for the difference between the two machines: you probably haven't > restarted the client on the first machine yet, so its initial > read-write mount of /afs is still intact. You should probably use > that to make sure the /afs/.cell forced read-write mount of root.cell > is present, and rerelease. > From jason@rampaginggeek.com Wed Oct 24 02:41:10 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Tue, 23 Oct 2007 21:41:10 -0400 Subject: [OpenAFS] 1.4.5pre4 success on Mac OS X tiger ppc Message-ID: <471EA2B6.5010209@rampaginggeek.com> 1.4.5pre4 is working fine on my ppc powerbook running 10.4. Jason From mhm.saif@gmail.com Wed Oct 24 09:31:14 2007 From: mhm.saif@gmail.com (mohammed saif) Date: Wed, 24 Oct 2007 11:31:14 +0300 Subject: [OpenAFS] Linux Login Cluster with AFS Message-ID: Hi list, How are you doing? I have to do a project related to LLC (Linux Login Cluster) and AFS (Andrew File System). Please if you know some manuals to read about these ideas and how to implement them together, PLEASE inform me. I'm googling since 2 days but there is nothing appropriate till now except some principles. I tried to test the AFS by downloading and installing the packages from www.openafs.org but most documentations concentrate on using the IBM AFS CD-ROM (To have some modules that I couldn't find through the net). If its necessary I can recommend to buy the software. but I do need some extensive manuals for both together to get the big picture. Please send me any ideas. Best Regards Mohammad From volstrup@s-et.aau.dk Wed Oct 24 12:34:51 2007 From: volstrup@s-et.aau.dk (Jacob Volstrup) Date: Wed, 24 Oct 2007 13:34:51 +0200 Subject: [OpenAFS] Automatic move of volumes Message-ID: <1193225691.11351.34.camel@thor> Hi, For quite some time I've been searching for something to help me move some volumes from a constantly failing /vicepa raid to my new /vicepb. The reason for not doing this manually is partly that I'm lazy and Further, I would like to have this fully automated if I would like to move them back in the future (perhaps when the disks for /vicepa are replaced). So my big question is if there exists anything to help migrate volumes from one partition to another which keeps the mount point intact? Sincerely, Jacob Volstrup From sdevine@msu.edu Wed Oct 24 13:03:55 2007 From: sdevine@msu.edu (Steve Devine) Date: Wed, 24 Oct 2007 08:03:55 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <1193225691.11351.34.camel@thor> References: <1193225691.11351.34.camel@thor> Message-ID: <471F34AB.4030601@msu.edu> Jacob Volstrup wrote: > Hi, > > For quite some time I've been searching for something to help me move > some volumes from a constantly failing /vicepa raid to my new /vicepb. > The reason for not doing this manually is partly that I'm lazy and > Further, I would like to have this fully automated if I would like to > move them back in the future (perhaps when the disks for /vicepa are > replaced). > > So my big question is if there exists anything to help migrate volumes > from one partition to another which keeps the mount point intact? > > Sincerely, Jacob Volstrup > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > The mount point(s) are independent of volume location. Thats the beauty of AFS you can move volumes at will and the user is unaware. Myself I get a root token and run vos listvol 'servername vicepX' >somefile and then grep out the RW vols and use a perl script to move em. If you have RO vols then you need to make sure you deal with them. But its pretty straight forward. No doubt there are more elegant ways to do this but I like a chance to review things as they go. /sd From fbo2@gmx.net Wed Oct 24 14:04:09 2007 From: fbo2@gmx.net (Frank Burkhardt) Date: Wed, 24 Oct 2007 15:04:09 +0200 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <1193225691.11351.34.camel@thor> References: <1193225691.11351.34.camel@thor> Message-ID: <20071024130409.GA29168@defiant.alpha> On Wed, Oct 24, 2007 at 01:34:51PM +0200, Jacob Volstrup wrote: > Hi, > > For quite some time I've been searching for something to help me move > some volumes from a constantly failing /vicepa raid to my new /vicepb. > The reason for not doing this manually is partly that I'm lazy and > Further, I would like to have this fully automated if I would like to > move them back in the future (perhaps when the disks for /vicepa are > replaced). If you can afford some downtime, the most efficient way is to simply copy the files from /vicepa to /vicepb on the server's filesystem: cd /vicepa;cp -a . /vicepb Make sure, /vicepb is empty before that. Warning: This worked for me lots of times but be carefull anyway. Regards, Frank From shadow@gmail.com Wed Oct 24 14:09:22 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 09:09:22 -0400 Subject: [OpenAFS] Linux Login Cluster with AFS In-Reply-To: References: Message-ID: ------=_Part_4903_4595078.1193231362176 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, mohammed saif wrote: > > Hi list, > > How are you doing? > > I have to do a project related to LLC (Linux Login Cluster) and AFS > (Andrew File System). Please if you know some manuals to read about > these ideas and how to implement them together, PLEASE inform me. I'm > googling since 2 days but there is nothing appropriate till now except > some principles. > > I tried to test the AFS by downloading and installing the packages > from www.openafs.org but most documentations concentrate on using the > IBM AFS CD-ROM (To have some modules that I couldn't find through the > net). If its necessary I can recommend to buy the software. but I do > need some extensive manuals for both together to get the big picture. > > Please send me any ideas. ./configure --enable-transarc-paths make dest and then you get something that looks like a cdrom, if that's really what you want. ------=_Part_4903_4595078.1193231362176 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, mohammed saif <mhm.saif@gmail.com> wrote:
Hi list,

How are you doing?

I have to do a project related to LLC (Linux Login Cluster) and AFS
(Andrew File System). Please if you know some manuals to read about
these ideas and how to implement them together, PLEASE inform me. I'm
googling since 2 days but there is nothing appropriate till now except
some principles.

I tried to test the AFS by downloading and installing the packages
from www.openafs.org but most documentations concentrate on using the
IBM AFS CD-ROM (To have some modules that I couldn't find through the
net). If its necessary I can recommend to buy the software. but I do
need some extensive manuals for both together to get the big picture.

Please send me any ideas.

./configure --enable-transarc-paths
make dest

and then you get something that looks like a cdrom, if that's really what you want.



------=_Part_4903_4595078.1193231362176-- From steven.jenkins@gmail.com Wed Oct 24 14:18:24 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 24 Oct 2007 09:18:24 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <471F34AB.4030601@msu.edu> References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: On 10/24/07, Steve Devine wrote: > Jacob Volstrup wrote: ...run vos listvol 'servername vicepX' > >somefile and then grep out the RW vols and use a perl script to move > em. If you have RO vols then you need to make sure you deal with them. > But its pretty straight forward. Assuming your new location does not already have the ROs on it: 1 vos listvol to get the list of volumes to move; if the old location is not empty, then, in this order: 2 For RO volumes: vos addsite to the new location, vos release, vos remove old ROs 3 For RW volumes: vos move 4 For .backup volumes: vos backup (or backupsys, depending on how you made them in the first place) once the RW volumes are moved 5 Goto 1 All this can be done while users are accessing their data, but if you do this at a relatively quiet time you can avoid some potential problems (eg, when this is done, snapshots are taken -- if the volserver can't get a 'good' snapshot, the vos move will fail; clients may see messages about a volume being busy; etc). Steven From shadow@gmail.com Wed Oct 24 14:29:02 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 09:29:02 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: ------=_Part_4964_10116244.1193232542815 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Steven Jenkins wrote: > > On 10/24/07, Steve Devine wrote: > > Jacob Volstrup wrote: > ...run vos listvol 'servername vicepX' > > >somefile and then grep out the RW vols and use a perl script to move > > em. If you have RO vols then you need to make sure you deal with them. > > But its pretty straight forward. > > > Assuming your new location does not already have the ROs on it: > > 1 vos listvol to get the list of volumes to move; if the old location > is not empty, then, in this order: > > 2 For RO volumes: vos addsite to the new location, vos release, vos > remove old ROs > 3 For RW volumes: vos move > 4 For .backup volumes: vos backup (or backupsys, depending on how you > made them in the first place) once the RW volumes are moved > 5 Goto 1 perl scripts exist to do it and I think have been posted here in the past; they may even deal with the "RO already exists" case. the interesting case is where the RW has unreleased changes and you want to recreate the ROs as they are now. i don't know of distributed tools to do this. ------=_Part_4964_10116244.1193232542815 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Steven Jenkins <steven.jenkins@gmail.com> wrote:
On 10/24/07, Steve Devine <sdevine@msu.edu> wrote:
> Jacob Volstrup wrote:
...run vos listvol 'servername vicepX'
>  >somefile and then grep out the RW vols and use a perl script to move
> em. If you have RO vols then you need to make sure you deal with them.
> But its pretty straight forward.


Assuming your new location does not already have the ROs on it:

1 vos listvol to get the list of volumes to move; if the old location
is not empty, then, in this order:

2 For RO volumes: vos addsite to the new location, vos release, vos
remove old ROs
3 For RW volumes: vos move
4 For .backup volumes: vos backup (or backupsys, depending on how you
made them in the first place) once the RW volumes are moved
5 Goto 1

perl scripts exist to do it and I think have been posted here in the past; they may even deal with the "RO already exists" case.

the interesting case is where the RW has unreleased changes and you want to recreate the ROs as they are now. i don't know of distributed tools to do this.


------=_Part_4964_10116244.1193232542815-- From sdevine@msu.edu Wed Oct 24 14:31:55 2007 From: sdevine@msu.edu (Steve Devine) Date: Wed, 24 Oct 2007 09:31:55 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <20071024130409.GA29168@defiant.alpha> References: <1193225691.11351.34.camel@thor> <20071024130409.GA29168@defiant.alpha> Message-ID: <471F494B.8000500@msu.edu> Frank Burkhardt wrote: > On Wed, Oct 24, 2007 at 01:34:51PM +0200, Jacob Volstrup wrote: > >> Hi, >> >> For quite some time I've been searching for something to help me move >> some volumes from a constantly failing /vicepa raid to my new /vicepb. >> The reason for not doing this manually is partly that I'm lazy and >> Further, I would like to have this fully automated if I would like to >> move them back in the future (perhaps when the disks for /vicepa are >> replaced). >> > > If you can afford some downtime, the most efficient way is to simply copy > the files from /vicepa to /vicepb on the server's filesystem: > > cd /vicepa;cp -a . /vicepb > > Make sure, /vicepb is empty before that. > > Warning: This worked for me lots of times but be carefull anyway. > > Regards, > > Frank > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > Wow this seems like a recipe for disaster. Do you then sync the vldb or rename the partiton to vicepa ? /sd -- Steve Devine Network Storage and Printing Academic Computing & Network Services Michigan State University 506 Computer Center East Lansing, MI 48824-1042 1-517-432-7327 Baseball is ninety percent mental; the other half is physical. - Yogi Berra From chas@cmf.nrl.navy.mil Wed Oct 24 14:51:42 2007 From: chas@cmf.nrl.navy.mil (chas williams - CONTRACTOR) Date: Wed, 24 Oct 2007 09:51:42 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <1193225691.11351.34.camel@thor> Message-ID: <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> In message <1193225691.11351.34.camel@thor>,Jacob Volstrup writes: >For quite some time I've been searching for something to help me move >some volumes from a constantly failing /vicepa raid to my new /vicepb. >The reason for not doing this manually is partly that I'm lazy and >Further, I would like to have this fully automated if I would like to >move them back in the future (perhaps when the disks for /vicepa are >replaced). i wrote this a while back when i was migrating file servers. it takes 4 arguments, , and optionally the -ro flag to also move the read-only's. it generates a list of commands that you typically run with /bin/sh (or you could just pipe to sh), so if you want to revert your actions at a later save this as a script and do a little sed magic on it to reverse the actions. it doesnt deal with the duplicate readonly problems. that wouldnt be hard to add or you could just live with the errors. #!/usr/bin/perl eval "exec perl -S $0 $*" if $running_under_some_shell; $from_server = ""; $from_partition = ""; $to_server = ""; $to_partition = ""; $do_ro = 0; while ($_ = shift(@ARGV) ) { option: { /^-ro$/ && (++$do_ro, last option); /^-/ && do {print STDERR "bad option \"$_\"\n"; last option}; end: { $from_server eq "" && ($from_server = $_, last end); $from_partition eq "" && ($from_partition = $_, last end); $to_server eq "" && ($to_server = $_, last end); $to_partition eq "" && ($to_partition = $_, last end); } } } open(LISTVOL, "vos listvol $from_server $from_partition|"); while() { chop; ($volume, $volid, $rw, $size, $k, $status) = split; $volid =~ /[0-9]+/ && do { $rw eq "RW" && do { printf "vos move %s %s %s %s %s -verbose\n", $volume, $from_server, $from_partition, $to_server, $to_partition; }; $rw eq "RO" && $do_ro && do { $volume =~ s/\.readonly$//; printf "vos remsite %s %s %s\n", $from_server, $from_partition, $volume; printf "vos addsite %s %s %s\n", $to_server, $to_partition, $volume; printf "vos release %s -verbose -f\n", $volume; }; } } exit 0; From steven.jenkins@gmail.com Wed Oct 24 14:54:47 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 24 Oct 2007 09:54:47 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: On 10/24/07, Derrick Brashear wrote: ... > perl scripts exist to do it and I think have been posted here in the past; > they may even deal with the "RO already exists" case. > It would be nice if there were a repository of publically available contrib stuff like that. > the interesting case is where the RW has unreleased changes and you want to > recreate the ROs as they are now. i don't know of distributed tools to do > this. > I hadn't really thought about people intentionally keeping their RWs & ROs out of sync w/each other. I'm not clear why someone would want to do that -- could you elaborate? Steven From shadow@gmail.com Wed Oct 24 14:56:36 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 09:56:36 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: ------=_Part_5036_10700150.1193234196718 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Steven Jenkins wrote: > > On 10/24/07, Derrick Brashear wrote: > ... > > perl scripts exist to do it and I think have been posted here in the > past; > > they may even deal with the "RO already exists" case. > > > > It would be nice if there were a repository of publically available > contrib stuff like that. > > > the interesting case is where the RW has unreleased changes and you want > to > > recreate the ROs as they are now. i don't know of distributed tools to > do > > this. > > > > I hadn't really thought about people intentionally keeping their RWs & > ROs out of sync w/each other. I'm not clear why someone would want to > do that -- could you elaborate? using the RW as a the "beta" copy of data and releasing the changes after testing them. i know of web backend services using AFS set up this way. ------=_Part_5036_10700150.1193234196718 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Steven Jenkins <steven.jenkins@gmail.com> wrote:
On 10/24/07, Derrick Brashear <shadow@gmail.com> wrote:
...
> perl scripts exist to do it and I think have been posted here in the past;
> they may even deal with the "RO already exists" case.
>

It would be nice if there were a repository of publically available
contrib stuff like that.

> the interesting case is where the RW has unreleased changes and you want to
> recreate the ROs as they are now. i don't know of distributed tools to do
> this.
>

I hadn't really thought about people intentionally keeping their RWs &
ROs out of sync w/each other.  I'm not clear why someone would want to
do that -- could you elaborate?

using the RW as a the "beta" copy of data and releasing the changes after testing them. i know of web backend services using AFS set up this way.



------=_Part_5036_10700150.1193234196718-- From Lars.Richter@prodesigncad.de Wed Oct 24 15:00:55 2007 From: Lars.Richter@prodesigncad.de (Lars Richter) Date: Wed, 24 Oct 2007 16:00:55 +0200 Subject: [OpenAFS] file timestamp difference Message-ID: <471F5017.8050203@prodesigncad.de> Hi, we have got a strange behavior with file timestamps and so with our development environment. Example: A script creates 2 files "test1" and "test2" after each other. The timestamps difference for these files is only shown in the nanoseconds. At another client these timestamps has different nanoseconds and the order of the file creation changed. Client 1 ( creation host of these files ) ls -rtl --full-time * -rw-r--r-- 1 user_xyz users 25 2007-10-24 15:41:37.679114250 +0200 tes= t1 -rw-r--r-- 1 user_xyz users 25 2007-10-24 15:41:37.707112131 +0200 tes= t2 Client 2 ls -rtl --full-time * -rw-r--r-- 1 user_xyz users 25 2007-10-24 15:41:37.447816288 +0200 tes= t2 -rw-r--r-- 1 user_xyz users 25 2007-10-24 15:41:37.781485632 +0200 tes= t1 I also can reproduce this behavior. We are using openafs 1.4.4 for server and clients running RHEL. 4 ( kernel 2.6.9-55) Does anyone have any suggestions? Regards, Lars --=20 Dipl.-Inf. Lars Richter Pro Design Electronic GmbH Europaplatz 5, 99091 Erfurt phone: +49 361 55038-0 fax: +49 361 78930-80 www.prodesigncad.de Vertretungsberechtigte Gesch=E4ftsf=FChrer: Helmut Mahr, Ulrike Angersbach, Stephan R=F6slmair, Heiko Mauersberger Registergericht: Amtsgericht Traunstein Registernummer: HRB 13 002=20 From kevin@umd.edu Wed Oct 24 15:03:57 2007 From: kevin@umd.edu (Kevin Hildebrand) Date: Wed, 24 Oct 2007 10:03:57 -0400 (EDT) Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: We've actually had this need a number of times... Say for instance, you've installed a new version of software in volume X for testing purposes, or as Derrick suggests, using the volume as a web backend. Then you run out of disk space, have a failing server, etc, and you need to move the RO replications - there's no easy way to do so without releasing the volume. Kevin On Wed, 24 Oct 2007, Steven Jenkins wrote: > On 10/24/07, Derrick Brashear wrote: > ... >> perl scripts exist to do it and I think have been posted here in the past; >> they may even deal with the "RO already exists" case. >> > > It would be nice if there were a repository of publically available > contrib stuff like that. > >> the interesting case is where the RW has unreleased changes and you want to >> recreate the ROs as they are now. i don't know of distributed tools to do >> this. >> > > I hadn't really thought about people intentionally keeping their RWs & > ROs out of sync w/each other. I'm not clear why someone would want to > do that -- could you elaborate? > > Steven > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From sbrown7@umbc.edu Wed Oct 24 15:04:45 2007 From: sbrown7@umbc.edu (Steve Brown) Date: Wed, 24 Oct 2007 10:04:45 -0400 (EDT) Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: On Wed, 24 Oct 2007, Steven Jenkins wrote: > I hadn't really thought about people intentionally keeping their RWs & > ROs out of sync w/each other. I'm not clear why someone would want to > do that -- could you elaborate? Test packages in the RO volume to make sure that stuff works as expected before releasing them into the wild? Steve Brown sbrown7@umbc.edu From sebby@anl.gov Wed Oct 24 15:10:07 2007 From: sebby@anl.gov (Brian Sebby) Date: Wed, 24 Oct 2007 09:10:07 -0500 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: <20071024141007.GA19562@atalanta.it.anl.gov> On Wed, Oct 24, 2007 at 09:56:36AM -0400, Derrick Brashear wrote: > On 10/24/07, Steven Jenkins wrote: > > > > On 10/24/07, Derrick Brashear wrote: > > ... > > > perl scripts exist to do it and I think have been posted here in the > > past; > > > they may even deal with the "RO already exists" case. > > > > > > > It would be nice if there were a repository of publically available > > contrib stuff like that. > > > > > the interesting case is where the RW has unreleased changes and you want > > to > > > recreate the ROs as they are now. i don't know of distributed tools to > > do > > > this. > > > > > > > I hadn't really thought about people intentionally keeping their RWs & > > ROs out of sync w/each other. I'm not clear why someone would want to > > do that -- could you elaborate? > > > using the RW as a the "beta" copy of data and releasing the changes after > testing them. i know of web backend services using AFS set up this way. We do this with some of our web servers. It works pretty well for letting the developers preview data. As for scripts, we have a series of scripts to move volumes from one volume to another, which keep track of the RO and RW volumes, and handle the RO already exists case. Let me check with our admin who wrote them to see if he's ok with me posting them to the list. (I may also need to make sure there's nothing specific to our cell in the scripts.) Oh, and just another warning about directly moving files from the native file system from /vicepa to /vicepb, not only would I consider that to be dangerous to do in almost all cases, it also would only work if you're using namei. I know that most sites seem to be using namei these days, but I'm sure there are still a number of inode servers still around. Brian -- Brian Sebby (sebby@anl.gov) | Unix and Operation Services Phone: +1 630.252.9935 | Computing and Information Systems Fax: +1 630.252.4601 | Argonne National Laboratory From fbo2@gmx.net Wed Oct 24 15:13:55 2007 From: fbo2@gmx.net (Frank Burkhardt) Date: Wed, 24 Oct 2007 16:13:55 +0200 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <471F494B.8000500@msu.edu> References: <1193225691.11351.34.camel@thor> <20071024130409.GA29168@defiant.alpha> <471F494B.8000500@msu.edu> Message-ID: <20071024141355.GA30326@defiant.alpha> Hi, On Wed, Oct 24, 2007 at 09:31:55AM -0400, Steve Devine wrote: [snip] > >If you can afford some downtime, the most efficient way is to simply copy > >the files from /vicepa to /vicepb on the server's filesystem: > > > > cd /vicepa;cp -a . /vicepb > > > >Make sure, /vicepb is empty before that. > > > >Warning: This worked for me lots of times but be carefull anyway. > > > >Regards, > > > >Frank > >_______________________________________________ > >OpenAFS-info mailing list > >OpenAFS-info@openafs.org > >https://lists.openafs.org/mailman/listinfo/openafs-info > > > Wow this seems like a recipe for disaster. Do you then sync the vldb or > rename the partiton to vicepa Sorry - I forgot. Of course the data partition name has to be the same after the copy process. I tried it once using syncvldb and ended up having multiple RW instances of the same volume on the server. I mostly use cp for simple harddisk upgrades (on small machines). For Multi-TB-servers vos move to a different server is the better choice mainly because of the low uptime. Regards, Frank From steven.jenkins@gmail.com Wed Oct 24 15:15:34 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 24 Oct 2007 10:15:34 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> References: <1193225691.11351.34.camel@thor> <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> Message-ID: It's great that you sent actual code. However, - there is no error checking in here, so there are potential issues (I realize your script is generating the commands, not actually doing them, but it still needs to address error checking -- if nothing else stick a '|| exit 1' at the end of each command) - handling RWs first will break RW/RO clones (if any exist) -- you probably don't want to do that. - the RO handling is not good -- what happens if the _only_ RO is on the old server and the remsite happens? Clients with existing connections & callbacks are ok, but any new clients needing that data now have no place to get it (even though the RO exists, the vldb doesn't know about it, so clients will go against the RW instead). Also, the actual data is left on the old fileserver ,which may (or may not) cause a problem down the road. Much better is to do a vos remove (which updates both the vldb & file server) after the new clone has been brought on line. - in general, handling RW/RO pairs is best handled separately I realize my 'general idea' email isn't complete enough to really build a robust script. Steven On 10/24/07, chas williams - CONTRACTOR wrote: ... > $rw eq "RO" && $do_ro && do > { > $volume =~ s/\.readonly$//; > > printf "vos remsite %s %s %s\n", $from_server, $from_partition, $volume; > printf "vos addsite %s %s %s\n", $to_server, $to_partition, $volume; > printf "vos release %s -verbose -f\n", $volume; > }; > } > From cclausen@acm.org Wed Oct 24 15:22:39 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Wed, 24 Oct 2007 09:22:39 -0500 Subject: [OpenAFS] Automatic move of volumes References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: <35C675C44B5042298B87A5850B4FB7CD@CDCHOME> Steven Jenkins wrote: > On 10/24/07, Derrick Brashear wrote: >> perl scripts exist to do it and I think have been posted here in the >> past; they may even deal with the "RO already exists" case. > > It would be nice if there were a repository of publically available > contrib stuff like that. I've offered to maintain such a thing if someone would be willing to grant AFS space in some part of a public cell. I can't really host things at UIUC due to various campus network usage policies. And actually, with AFS we can just create a mount point to a world readable volume in any public cell so that the contributor can maintain the most up to date version without involving someone in updating the content. >> the interesting case is where the RW has unreleased changes and you >> want to recreate the ROs as they are now. i don't know of >> distributed tools to do this. > > I hadn't really thought about people intentionally keeping their RWs & > ROs out of sync w/each other. I'm not clear why someone would want to > do that -- could you elaborate? Yes, I do this. This isn't easy to work around either as I'm pretty sure that vos dump and vos copy specifically prevent you from doing operations on an RO volume. For instance I may pre-stage content for a website that is to be released next week at 10a on Monday. I can then cron the release and have the data show up exactly at a specific time. However, what usually happens is that some last minute change needs to be made to the current live website and its not easy to undo the new site, make the change, and then re-release. I generally end up deleting (copying elsewhere first of course) the contents of the RW with rm, copying the RO, making changes and re-releasing. And then putting back the pre-staged content. < References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: On 10/24/07, Kevin Hildebrand wrote: > > We've actually had this need a number of times... Say for instance, > you've installed a new version of software in volume X for testing > purposes, or as Derrick suggests, using the volume as a web backend. > > Then you run out of disk space, have a failing server, etc, and you need > to move the RO replications - there's no easy way to do so without > releasing the volume. > I sort of understand this need, but I suggest that it's caused by poor namespace management, and that the solution should be to improve that rather than try to keep your RWs and ROs out of sync with each other. There are several ways to have versionized trees: two are - at the top (ie, different root volumes) - in the middle of the filesystem space via symlinks (eg, have a volume 'in the middle' of your hierarchy that lets you have 'dev' and 'prod' links) -- take a look at slides 15 & 16 of http://www-conf.slac.stanford.edu/AFSBestPractices/Slides/MorganStanley.pdf for one way to do that Steven From shadow@gmail.com Wed Oct 24 15:30:12 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 10:30:12 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: ------=_Part_5206_29042462.1193236212495 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Steven Jenkins wrote: > > On 10/24/07, Kevin Hildebrand wrote: > > > > We've actually had this need a number of times... Say for instance, > > you've installed a new version of software in volume X for testing > > purposes, or as Derrick suggests, using the volume as a web backend. > > > > Then you run out of disk space, have a failing server, etc, and you need > > to move the RO replications - there's no easy way to do so without > > releasing the volume. > > > > I sort of understand this need, but I suggest that it's caused by poor > namespace management, and that the solution should be to improve that > rather than try to keep your RWs and ROs out of sync with each other. not everyone has VMS. it has nothing to do with namespace management. nothing is as easy as "vos release" to copy data around. ------=_Part_5206_29042462.1193236212495 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Steven Jenkins <steven.jenkins@gmail.com> wrote:
On 10/24/07, Kevin Hildebrand <kevin@umd.edu> wrote:
>
> We've actually had this need a number of times...  Say for instance,
> you've installed a new version of software in volume X for testing
> purposes, or as Derrick suggests, using the volume as a web backend.
>
> Then you run out of disk space, have a failing server, etc, and you need
> to move the RO replications - there's no easy way to do so without
> releasing the volume.
>

I sort of understand this need, but I suggest that it's caused by poor
namespace management, and that the solution should be to improve that
rather than try to keep your RWs and ROs out of sync with each other.

not everyone has VMS. it has nothing to do with namespace management. nothing is as easy as "vos release" to copy data around.


------=_Part_5206_29042462.1193236212495-- From steven.jenkins@gmail.com Wed Oct 24 15:38:53 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 24 Oct 2007 10:38:53 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <471F554D.5030402@dartmouth.edu> References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> <471F554D.5030402@dartmouth.edu> Message-ID: On 10/24/07, anne salemme wrote: ... > - having a well-known, scheduled time for releasing certain volumes > to ensure that files become available at an approximately-scheduled time > (useful for website management, or for dealing with vos releases of very > popular volumes typically near the top of an afs tree) ... What's wrong with simply doing vos dump with the timestamp then? And having an name encoding rule that lets you determine the base RW volume + timestamp. For example, 'base' volume = mydata 'timestamp' volume is md.2007102402 (for the snapshot created via vos dump mydata | vos restore at 2am) you can then create RO clones of md.2007102401; RO's of 'mydata' aren't needed cutting over from the md20071001 to md.2007102402 means an intermediate volume needs to exist that contains that change, but it's contents can be programmatically determined based on the time. You would have 'dev' and 'prod' links in that volume that always point to the hour-appropriate versions. In general, I now understand some of what people are doing with the RW/RO differences -- thanks for the explanations. But it seems to me that there are ways to deal with this -without- needing to keep RWs and ROs intentionally out of sync. It would be interesting, though, if vos addsite/release had a built-in generational mechanism to mark ROs. That could lead to other ways to solve these problems. Steven From haba@kth.se Wed Oct 24 15:43:27 2007 From: haba@kth.se (Harald Barth) Date: Wed, 24 Oct 2007 16:43:27 +0200 (MEST) Subject: [OpenAFS] file timestamp difference In-Reply-To: <471F5017.8050203@prodesigncad.de> References: <471F5017.8050203@prodesigncad.de> Message-ID: <20071024.164327.76527676.haba@habarber.pdc.kth.se> > I also can reproduce this behavior. Do all clients but the one you created the files on show identical file dates? Harald. From chas@cmf.nrl.navy.mil Wed Oct 24 16:04:05 2007 From: chas@cmf.nrl.navy.mil (chas williams - CONTRACTOR) Date: Wed, 24 Oct 2007 11:04:05 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: Message-ID: <200710241504.l9OF45r3023922@cmf.nrl.navy.mil> In message ,"Steve n Jenkins" writes: >- there is no error checking in here, so there are potential issues (I >realize your script is generating the commands, not actually doing >them, but it still needs to address error checking -- if nothing else >stick a '|| exit 1' at the end of each command) you are free to add error checking. i dont make misteaks so i dont bother with error checking. >- handling RWs first will break RW/RO clones (if any exist) -- you >probably don't want to do that. to be honest, i usually run the script in two passes. doing the rw first, and later run it with the -ro flag. >- the RO handling is not good -- what happens if the _only_ RO is on >the old server and the remsite happens? Clients with existing never considered that since we dont have a single readonly for any volumes. if i have a readonly, i have more than one site. >- in general, handling RW/RO pairs is best handled separately you could just change the order a bit. it should zap the old readonly to force the old users of the readonly to the new readonly to get them off the sever asap. From allbery@ece.cmu.edu Wed Oct 24 16:09:39 2007 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed, 24 Oct 2007 11:09:39 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: On Oct 24, 2007, at 9:54 , Steven Jenkins wrote: > On 10/24/07, Derrick Brashear wrote: > ... >> the interesting case is where the RW has unreleased changes and >> you want to >> recreate the ROs as they are now. i don't know of distributed >> tools to do >> this. > > I hadn't really thought about people intentionally keeping their RWs & > ROs out of sync w/each other. I'm not clear why someone would want to > do that -- could you elaborate? Version control on the cheap: the R/O contains the publicly supported version, the R/W is the development/testing one. When it's tested and ready for deployment, release the volume. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery@ece.cmu.edu Wed Oct 24 16:12:36 2007 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed, 24 Oct 2007 11:12:36 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> Message-ID: <72222D85-B740-433A-B588-53BC12F05A7A@ece.cmu.edu> On Oct 24, 2007, at 10:15 , Steven Jenkins wrote: > - there is no error checking in here, so there are potential issues (I > realize your script is generating the commands, not actually doing > them, but it still needs to address error checking -- if nothing else > stick a '|| exit 1' at the end of each command) "set -e" is your friend. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From scs@umich.edu Wed Oct 24 16:14:30 2007 From: scs@umich.edu (Steve Simmons) Date: Wed, 24 Oct 2007 11:14:30 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <35C675C44B5042298B87A5850B4FB7CD@CDCHOME> References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> <35C675C44B5042298B87A5850B4FB7CD@CDCHOME> Message-ID: <79FD9647-4F04-4721-971E-DA6216D7EF63@umich.edu> On Oct 24, 2007, at 10:22 AM, Christopher D. Clausen wrote: > Steven Jenkins wrote: >> On 10/24/07, Derrick Brashear wrote: >>> perl scripts exist to do it and I think have been posted here in the >>> past; they may even deal with the "RO already exists" case. >> >> It would be nice if there were a repository of publically available >> contrib stuff like that. > > I've offered to maintain such a thing if someone would be willing to > grant AFS space in some part of a public cell. I can't really host > things at UIUC due to various campus network usage policies. > > And actually, with AFS we can just create a mount point to a world > readable volume in any public cell so that the contributor can > maintain > the most up to date version without involving someone in updating the > content. I'd be happy to pitch in on this; there are a number of useful things out there when don't properly belong in the distribution but would be really nice to have in a common place. I'll check with our management to see if we can devote a volume. Steve From Lars.Richter@prodesigncad.de Wed Oct 24 16:33:14 2007 From: Lars.Richter@prodesigncad.de (Lars Richter) Date: Wed, 24 Oct 2007 17:33:14 +0200 Subject: [OpenAFS] file timestamp difference In-Reply-To: <20071024.164327.76527676.haba@habarber.pdc.kth.se> References: <471F5017.8050203@prodesigncad.de> <20071024.164327.76527676.haba@habarber.pdc.kth.se> Message-ID: <471F65BA.6090509@prodesigncad.de> Harald Barth schrieb: 
I also can reproduce this behavior.
    

Do all clients but the one you created the files on show identical file dates?

Harald.

No.

All clients have different dates in the nanoseconds. All other values are identical!

Lars


-- 
Dipl.-Inf. Lars Richter
Pro Design Electronic GmbH
Europaplatz 5, 99091 Erfurt
phone: +49 361 55038-25
fax:   +49 361 78930-80
www.prodesigncad.de

Vertretungsberechtigte Geschäftsführer:
Helmut Mahr, Ulrike Angersbach, Stephan Röslmair, Heiko Mauersberger

Registergericht: Amtsgericht Traunstein
Registernummer: HRB 13 002
From allbery@ece.cmu.edu Wed Oct 24 16:36:25 2007 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed, 24 Oct 2007 11:36:25 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: <9BD2F8D3-6E4D-4074-B57C-10DB1EA45D6B@ece.cmu.edu> On Oct 24, 2007, at 10:25 , Steven Jenkins wrote: > I sort of understand this need, but I suggest that it's caused by poor > namespace management, and that the solution should be to improve that > rather than try to keep your RWs and ROs out of sync with each other. I think you're misunderstanding; the RO vs RW is only one component of such a scheme. (Except in the case of simple htdocs staging.) In our environment, software collections are arranged into releases; the vast majority of machines subscribe to the omega release, test machines may subscribe to alpha / beta / gamma / various custom/ testing release snapshots (and fall back to omega if those don't exist), development machines may subscribe to the RW volume instead of the RO to get the most up to date code instead of a snapshot. (Omega fallback still works here, as the RW omega release should always match the RO except (a) when it's a brand new package, so there is no RO (b) in the middle of an omega release update, which is typically very short because all you're doing is moving symlinks around.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery@ece.cmu.edu Wed Oct 24 16:40:39 2007 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed, 24 Oct 2007 11:40:39 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> Message-ID: <114245A7-806E-40B4-9214-6B7BABF955D5@ece.cmu.edu> On Oct 24, 2007, at 10:15 , Steven Jenkins wrote: > - the RO handling is not good -- what happens if the _only_ RO is on > the old server and the remsite happens? Clients with existing remsite is irrelevant: it just informs the vlserver of where an R/O replica will be stored in the future, it has no impact whatsoever on what R/Os (if any) exist *now*. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery@ece.cmu.edu Wed Oct 24 16:44:10 2007 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed, 24 Oct 2007 11:44:10 -0400 Subject: [OpenAFS] file timestamp difference In-Reply-To: <471F65BA.6090509@prodesigncad.de> References: <471F5017.8050203@prodesigncad.de> <20071024.164327.76527676.haba@habarber.pdc.kth.se> <471F65BA.6090509@prodesigncad.de> Message-ID: On Oct 24, 2007, at 11:33 , Lars Richter wrote: > Harald Barth schrieb: >>> I also can reproduce this behavior. >> Do all clients but the one you created the files on show identical >> file dates? Harald. > > No. > > All clients have different dates in the nanoseconds. All other > values are identical! I don't think AFS stores file timestamps with subsecond granularity. This might therefore be considered a client bug (perhaps it should just zero the nanoseconds). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From steven.jenkins@gmail.com Wed Oct 24 16:48:06 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 24 Oct 2007 11:48:06 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <114245A7-806E-40B4-9214-6B7BABF955D5@ece.cmu.edu> References: <1193225691.11351.34.camel@thor> <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> <114245A7-806E-40B4-9214-6B7BABF955D5@ece.cmu.edu> Message-ID: On 10/24/07, Brandon S. Allbery KF8NH wrote: > > On Oct 24, 2007, at 10:15 , Steven Jenkins wrote: > > > - the RO handling is not good -- what happens if the _only_ RO is on > > the old server and the remsite happens? Clients with existing > > remsite is irrelevant: it just informs the vlserver of where an R/O > replica will be stored in the future, it has no impact whatsoever on > what R/Os (if any) exist *now*. > > -- remsite is _very_ relevant for clients that don't already know about the RO that has been remsite'd -- when they ask the vlserver for the volume, the vlserver will tell them that only the RW exists. Steven From cclausen@acm.org Wed Oct 24 17:18:15 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Wed, 24 Oct 2007 11:18:15 -0500 Subject: [OpenAFS] Automatic move of volumes References: <1193225691.11351.34.camel@thor> <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> <114245A7-806E-40B4-9214-6B7BABF955D5@ece.cmu.edu> Message-ID: <18D2A9EC87A847B283EA4452ADDE6145@CDCHOME> Steven Jenkins wrote: > On 10/24/07, Brandon S. Allbery KF8NH wrote: >> On Oct 24, 2007, at 10:15 , Steven Jenkins wrote: >>> - the RO handling is not good -- what happens if the _only_ RO is on >>> the old server and the remsite happens? Clients with existing >> >> remsite is irrelevant: it just informs the vlserver of where an R/O >> replica will be stored in the future, it has no impact whatsoever on >> what R/Os (if any) exist *now*. > > remsite is _very_ relevant for clients that don't already know about > the RO that has been remsite'd -- when they ask the vlserver for the > volume, the vlserver will tell them that only the RW exists. That sounds like a mis-use of the remsite command, although that is an interesting way to "hide" RO volumes. I assume that a client that gets rebooted / crashes is going to start reading the RW when it comes back up though, right? < References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: On 10/24/07, Derrick Brashear wrote: ... > not everyone has VMS. *nod*, although it has been documented in public (at least some of the pieces) for quite some time. It seems CMU takes a similar approach, and I suspect others out there have 'rolled their own'. From the 'me too's using vos release to handle versioning, it appears having a general system more widely available would scratch a real itch. > it has nothing to do with namespace management. > nothing is as easy as "vos release" to copy data around. > It has _everything_ to do with namespace management. In absence of better tools, people are using vos release to do just that. Note that vos release isn't a bad tool; it's just being stretched beyond its design because people need a way to do versioning of their namespaces. I think it would be very useful if someone had the time/energy to build a 'vms-lite' that people could adopt at their sites. That seems a more strategic direction than trying to extend RO capabilities. That may be more of an openafs-devel or AFS3-standardization discussion rather than openafs-info, though -- I don't know. I also realize that building something like that is non-trivial. If people are interested in doing that, though, it seems a widely-needed tool. Steven From lw@lwilke.de Wed Oct 24 17:25:20 2007 From: lw@lwilke.de (Lars Wilke) Date: Wed, 24 Oct 2007 18:25:20 +0200 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: <20071024162520.GA9148@ckLennard.net.home> * Steven Jenkins wrote: > http://www-conf.slac.stanford.edu/AFSBestPractices/Slides/MorganStanley.pdf Interesting, is there any more information available about the points mentioned on the last 3 slides? cheers --lars From shadow@gmail.com Wed Oct 24 17:29:05 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 12:29:05 -0400 Subject: [OpenAFS] file timestamp difference In-Reply-To: <20071024.164327.76527676.haba@habarber.pdc.kth.se> References: <471F5017.8050203@prodesigncad.de> <20071024.164327.76527676.haba@habarber.pdc.kth.se> Message-ID: ------=_Part_5742_30737298.1193243345153 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Harald Barth wrote: > > > > I also can reproduce this behavior. > > Do all clients but the one you created the files on show identical file > dates? i'll bet no. ------=_Part_5742_30737298.1193243345153 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Harald Barth <haba@kth.se> wrote:

> I also can reproduce this behavior.

Do all clients but the one you created the files on show identical file dates?

i'll bet no.
 


------=_Part_5742_30737298.1193243345153-- From shadow@gmail.com Wed Oct 24 17:34:58 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 12:34:58 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: ------=_Part_5779_29023495.1193243698628 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Steven Jenkins wrote: > > On 10/24/07, Derrick Brashear wrote: > ... > > not everyone has VMS. > > *nod*, although it has been documented in public (at least some of the > pieces) for quite some time. It seems CMU takes a similar approach, > and I suspect others out there have 'rolled their own'. From the 'me > too's using vos release to handle versioning, it appears having a > general system more widely available would scratch a real itch. where's Phil so I can beat him up some more? > It has _everything_ to do with namespace management. In absence of > better tools, people are using vos release to do just that. Note that > vos release isn't a bad tool; it's just being stretched beyond its > design because people need a way to do versioning of their namespaces. you want to dump and restore volumes. that's ugly. it's not a namespace issue; you want versioned volume clones. ------=_Part_5779_29023495.1193243698628 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Steven Jenkins <steven.jenkins@gmail.com> wrote:
On 10/24/07, Derrick Brashear <shadow@gmail.com> wrote:
...
> not everyone has VMS.

*nod*, although it has been documented in public (at least some of the
pieces) for quite some time.  It seems CMU takes a similar approach,
and I suspect others out there have 'rolled their own'.  From the 'me
too's using vos release to handle versioning, it appears having a
general system more widely available would scratch a real itch.

where's Phil so I can beat him up some more?


It has _everything_ to do with namespace management.  In absence of
better tools, people are using vos release to do just that.  Note that
vos release isn't a bad tool; it's just being stretched beyond its
design because people need a way to do versioning of their namespaces.

you want to dump and restore volumes. that's ugly. it's not a namespace issue; you want versioned volume clones.
 

------=_Part_5779_29023495.1193243698628-- From shadow@gmail.com Wed Oct 24 17:50:21 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 12:50:21 -0400 Subject: [OpenAFS] file timestamp difference In-Reply-To: <471F65BA.6090509@prodesigncad.de> References: <471F5017.8050203@prodesigncad.de> <20071024.164327.76527676.haba@habarber.pdc.kth.se> <471F65BA.6090509@prodesigncad.de> Message-ID: ------=_Part_5852_7302113.1193244621999 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/24/07, Lars Richter wrote: > > Harald Barth schrieb: > > I also can reproduce this behavior. > > > Do all clients but the one you created the files on show identical file = dates? > > Harald. > > > > No. > > All clients have different dates in the nanoseconds. All other values are > identical! > > Lars > > > -- > Dipl.-Inf. Lars Richter > Pro Design Electronic GmbH > Europaplatz 5, 99091 Erfurt > phone: +49 361 55038-25 > fax: +49 361 78930-80www.prodesigncad.de > > Vertretungsberechtigte Gesch=E4ftsf=FChrer: > Helmut Mahr, Ulrike Angersbach, Stephan R=F6slmair, Heiko Mauersberger > > Registergericht: Amtsgericht Traunstein > Registernummer: HRB 13 002 > > _______________________________________________ OpenAFS-info mailing lis= t > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info ------=_Part_5852_7302113.1193244621999 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 10/24/07, Lars Richter <Lars.Richter@prodesigncad.de> wrote:
=20
Harald Barth schrieb: 
I also can reproduce this behavior.
    
Do all clients but the one you created the files on show identical f=
ile dates?

Harald.

No.

All clients have different dates in the nanoseconds. All other values are identical!

Lars


--=20
Dipl.-Inf. Lars Richter
Pro Design Electronic GmbH
Europaplatz 5, 99091 Erfurt
phone: +49 361 55038-25
fax:   +49 361 78930-80
www.prodesigncad.de

Vertretungsberechtigte Gesch=E4ftsf=FChrer:
Helmut Mahr, Ulrike Angersbach, Stephan R=F6slmair, Heiko Mauersberger

Registergericht: Amtsgericht Traunstein
Registernummer: HRB 13 002=20
_______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https:= //lists.openafs.org/mailman/listinfo/openafs-info

------=_Part_5852_7302113.1193244621999-- From steven.jenkins@gmail.com Wed Oct 24 17:53:51 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 24 Oct 2007 12:53:51 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: On 10/24/07, Derrick Brashear wrote: > ... > where's Phil so I can beat him up some more? > Heh. He's about 100 feet from where you got your most recent Mac. But you'll have to get through Security unless you can lure him out by offering him another tattoo or something.. And, for the record, my money is on Phil unless you bring a ranged weapon or have the element of surprise. > > > > It has _everything_ to do with namespace management. In absence of > > better tools, people are using vos release to do just that. Note that > > vos release isn't a bad tool; it's just being stretched beyond its > > design because people need a way to do versioning of their namespaces. > > you want to dump and restore volumes. that's ugly. it's not a namespace > issue; you want versioned volume clones. > dump/restore is just a mechanism in lieu of a volume copy operation. Versionized clones could be interesting in this context, but I would prefer to stay away from that approach as it makes it harder to recover & see changes in the base volume. I think having one RW per 'generation' of ROs is reasonable. With versionized clones, you would need to create a mechanism to have potentially infinite numbers of clones, with arbitrary generation identifiers (eg, some would be ok with '1', '2', ..., but some would want 'alpha', 'beta', ..., or 'dev', 'prod', etc). IMO, that's better done outside of the volume itself. Steven From shadow@gmail.com Wed Oct 24 18:00:17 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 13:00:17 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> Message-ID: ------=_Part_5886_13047655.1193245217602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Steven Jenkins wrote: > > On 10/24/07, Derrick Brashear wrote: > > ... > > where's Phil so I can beat him up some more? > > > > Heh. He's about 100 feet from where you got your most recent Mac. > But you'll have to get through Security unless you can lure him out by > offering him another tattoo or something.. he's on the 4th floor?? And, for the record, my money is on Phil unless you bring a ranged > weapon or have the element of surprise. well, if he's not reading.... > > dump/restore is just a mechanism in lieu of a volume copy operation. > Versionized clones could be interesting in this context, but I would > prefer to stay away from that approach as it makes it harder to > recover & see changes in the base volume. I think having one RW per > 'generation' of ROs is reasonable. this is all implementation decisions, and the ones you make that make me wretch, well, i'm not running it so i don't matter. ------=_Part_5886_13047655.1193245217602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Steven Jenkins <steven.jenkins@gmail.com> wrote:
On 10/24/07, Derrick Brashear <shadow@gmail.com> wrote:
> ...
> where's Phil so I can beat him up some more?
>

Heh.  He's about 100 feet from where you got your most recent Mac.
But you'll have to get through Security unless you can lure him out by
offering him another tattoo or something..

he's on the 4th floor??

And, for the record, my money is on Phil unless you bring a ranged
weapon or have the element of surprise.

well, if he's not reading....



dump/restore is just a mechanism in lieu of a volume copy operation.
Versionized clones could be interesting in this context, but I would
prefer to stay away from that approach as it makes it harder to
recover & see changes in the base volume.  I think having one RW per
'generation' of ROs is reasonable.

this is all implementation decisions, and the ones you make that make me wretch, well, i'm not running it so i don't matter.


------=_Part_5886_13047655.1193245217602-- From steven.jenkins@gmail.com Wed Oct 24 18:01:33 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 24 Oct 2007 13:01:33 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <18D2A9EC87A847B283EA4452ADDE6145@CDCHOME> References: <1193225691.11351.34.camel@thor> <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> <114245A7-806E-40B4-9214-6B7BABF955D5@ece.cmu.edu> <18D2A9EC87A847B283EA4452ADDE6145@CDCHOME> Message-ID: On 10/24/07, Christopher D. Clausen wrote: ... > That sounds like a mis-use of the remsite command, although that is an > interesting way to "hide" RO volumes. > Keep in mind the context of my comment -- I was looking at someone's 'move volumes en masse' code. It's not how I would recommend handling things. > I assume that a client that gets rebooted / crashes is going to start > reading the RW when it comes back up though, right? > Right. Clients don't even have to reboot, though: vldb information times out after 2 hrs, iirc. Steven From steven.jenkins@gmail.com Wed Oct 24 18:08:52 2007 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 24 Oct 2007 13:08:52 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> Message-ID: On 10/24/07, Derrick Brashear wrote: > .... > > dump/restore is just a mechanism in lieu of a volume copy operation. > > Versionized clones could be interesting in this context, but I would > > prefer to stay away from that approach as it makes it harder to > > recover & see changes in the base volume. I think having one RW per > > 'generation' of ROs is reasonable. > > this is all implementation decisions, and the ones you make that make me > wretch, well, i'm not running it so i don't matter. > It's a community/gatekeeper/elder/afs3-standardization issue: if the Road Ahead has generational clones, that's one thing. If it doesn't, then it would be helpful to know. As for wretched decisions, I'm always open to hearing about better ways to do things. Steven From jblaine@kickflop.net Wed Oct 24 18:41:15 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Wed, 24 Oct 2007 13:41:15 -0400 Subject: [OpenAFS] openafs.org downloads - Kerberos 5 or not? Message-ID: <471F83BB.9050400@kickflop.net> It's my assumption that none of the 1.5 or 1.4 builds of OpenAFS at openafs.org are built to use Kerberos 5. None of them say yes/no. Is that correct? From rees@umich.edu Wed Oct 24 18:59:09 2007 From: rees@umich.edu (Jim Rees) Date: Wed, 24 Oct 2007 13:59:09 -0400 Subject: [OpenAFS] file timestamp difference In-Reply-To: <471F5017.8050203@prodesigncad.de> References: <471F5017.8050203@prodesigncad.de> Message-ID: <20071024175909.GB27639@citi.umich.edu> Here's an interesting nugget from LINUX/osi_vfsops.c:vattr2inode(): #if defined(AFS_LINUX26_ENV) ip->i_atime.tv_sec = vp->va_atime.tv_sec; ip->i_mtime.tv_sec = vp->va_mtime.tv_sec; /* Set the mtime nanoseconds to the sysname generation number. * This convinces NFS clients that all directories have changed * any time the sysname list changes. */ ip->i_mtime.tv_nsec = afs_sysnamegen; ip->i_ctime.tv_sec = vp->va_ctime.tv_sec; #else Seems like a bug to me. This should be: #if defined(AFS_LINUX26_ENV) ip->i_atime = vp->va_atime; ip->i_mtime = vp->va_mtime; ip->i_ctime = vp->va_ctime; #else What do you get from "ls -rtlc --full-time *"? From cluniac@gmail.com Wed Oct 24 12:17:08 2007 From: cluniac@gmail.com (Matthew1) Date: Wed, 24 Oct 2007 04:17:08 -0700 (PDT) Subject: [OpenAFS] Using OpenAFS client with AFS Server 3.6 Message-ID: <13383657.post@talk.nabble.com> Hello, I am working on a project which wants to utilize the OpenAFS client to connect to an AFS server running version 3.6. So far we have been unable to find out if this will work ok. Can anyone provide information on this, and perhaps direct us to where we can see the compatability of OpenAFS with other AFS products? Thanks, Matt -- View this message in context: http://www.nabble.com/Using-OpenAFS-client-with-AFS-Server-3.6-tf4683670.html#a13383657 Sent from the OpenAFS - General mailing list archive at Nabble.com. From anne.salemme@Dartmouth.EDU Wed Oct 24 15:23:09 2007 From: anne.salemme@Dartmouth.EDU (anne salemme) Date: Wed, 24 Oct 2007 10:23:09 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: <471F554D.5030402@dartmouth.edu> Steven Jenkins wrote: > .... > > I hadn't really thought about people intentionally keeping their RWs & > ROs out of sync w/each other. I'm not clear why someone would want to > do that -- could you elaborate? > > Steven > some examples: - putting in a new version of some software, and and trying it out before releasing it to the community - having a well-known, scheduled time for releasing certain volumes to ensure that files become available at an approximately-scheduled time (useful for website management, or for dealing with vos releases of very popular volumes typically near the top of an afs tree) so...instead of doing random vos releases, in some sites you need to coordinate the vos releasing of volumes, schedule some, or do some only on request. depends on the usage in the cell and what you need to accomplish. anne From anne.salemme@Dartmouth.EDU Wed Oct 24 16:16:21 2007 From: anne.salemme@Dartmouth.EDU (anne salemme) Date: Wed, 24 Oct 2007 11:16:21 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: <471F61C5.1080206@dartmouth.edu> and to add to what derrick says, 'vos release' when there are very large volumes involved and RO sites listed at geographically remote sites (ie, many thousands of miles away), or when there are many users involved (ie, all users of the cell) must be done in a purposeful, coordinated way. and just "always keeping the RWs and ROs in sync" simply cannot or should not be done. anne Derrick Brashear wrote: > > > On 10/24/07, *Steven Jenkins* > wrote: > > On 10/24/07, Kevin Hildebrand > wrote: > > > > We've actually had this need a number of times... Say for instance, > > you've installed a new version of software in volume X for testing > > purposes, or as Derrick suggests, using the volume as a web backend. > > > > Then you run out of disk space, have a failing server, etc, and > you need > > to move the RO replications - there's no easy way to do so without > > releasing the volume. > > > > I sort of understand this need, but I suggest that it's caused by poor > namespace management, and that the solution should be to improve that > rather than try to keep your RWs and ROs out of sync with each other. > > > not everyone has VMS. it has nothing to do with namespace management. > nothing is as easy as "vos release" to copy data around. > > From shadow@gmail.com Wed Oct 24 19:25:35 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 14:25:35 -0400 Subject: [OpenAFS] file timestamp difference In-Reply-To: <20071024175909.GB27639@citi.umich.edu> References: <471F5017.8050203@prodesigncad.de> <20071024175909.GB27639@citi.umich.edu> Message-ID: ------=_Part_6103_20444032.1193250335047 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Jim Rees wrote: > > Here's an interesting nugget from LINUX/osi_vfsops.c:vattr2inode(): in 1.5. look at 1.4 ------=_Part_6103_20444032.1193250335047 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Jim Rees <rees@umich.edu> wrote:
Here's an interesting nugget from LINUX/osi_vfsops.c:vattr2inode():

in 1.5. look at 1.4


------=_Part_6103_20444032.1193250335047-- From shadow@gmail.com Wed Oct 24 19:45:34 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 14:45:34 -0400 Subject: [OpenAFS] openafs.org downloads - Kerberos 5 or not? In-Reply-To: <471F83BB.9050400@kickflop.net> References: <471F83BB.9050400@kickflop.net> Message-ID: ------=_Part_6155_6942224.1193251534295 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Jeff Blaine wrote: > > It's my assumption that none of the 1.5 or 1.4 > builds of OpenAFS at openafs.org are built to use > Kerberos 5. You'll have to be more specific about what you mean by that. MacOS X certainly includes a krb5 aklog. ------=_Part_6155_6942224.1193251534295 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Jeff Blaine <jblaine@kickflop.net> wrote:
It's my assumption that none of the 1.5 or 1.4
builds of OpenAFS at openafs.org are built to use
Kerberos 5.

You'll have to be more specific about what you mean by that.

MacOS X certainly includes a krb5 aklog.

------=_Part_6155_6942224.1193251534295-- From jblaine@kickflop.net Wed Oct 24 19:57:38 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Wed, 24 Oct 2007 14:57:38 -0400 Subject: [OpenAFS] Re: openafs.org downloads - Kerberos 5 or not? Message-ID: <471F95A2.70904@kickflop.net> "It's my assumption that none of the 1.5 or 1.4 builds of OpenAFS at openafs.org are built to use Kerberos 5." (More specific) Well, building OpenAFS for Kerberos 5 support requires headers, libraries, and certain configure options. What, if any, releases on openafs.org were built this way? Or do we assume that if one is using Kerberos 5, always build from source? From shadow@gmail.com Wed Oct 24 20:06:27 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 24 Oct 2007 15:06:27 -0400 Subject: [OpenAFS] Re: openafs.org downloads - Kerberos 5 or not? In-Reply-To: <471F95A2.70904@kickflop.net> References: <471F95A2.70904@kickflop.net> Message-ID: ------=_Part_6245_1746531.1193252787834 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Jeff Blaine wrote: > > "It's my assumption that none of the 1.5 or 1.4 > builds of OpenAFS at openafs.org are built to use > Kerberos 5." > > (More specific) > > Well, building OpenAFS for Kerberos 5 support requires > headers, libraries, and certain configure options. if the vendor provides krb5, we use it. if not, it's hard to know which kerberos a site will use, so we don't. the simple test: does the vendor ship krb5? every linux. macos. starting in 1.4.5, aix 5 and opensolaris. ------=_Part_6245_1746531.1193252787834 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/24/07, Jeff Blaine <jblaine@kickflop.net> wrote:
     "It's my assumption that none of the 1.5 or 1.4
      builds of OpenAFS at openafs.org are built to use
      Kerberos 5."

(More specific)

Well, building OpenAFS for Kerberos 5 support requires
headers, libraries, and certain configure options.

if the vendor provides krb5, we use it.  if not, it's hard to know which kerberos a site will use, so we don't.

the simple test: does the vendor ship krb5?

every linux. macos. starting in 1.4.5, aix 5 and opensolaris.



------=_Part_6245_1746531.1193252787834-- From jblaine@kickflop.net Wed Oct 24 20:25:57 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Wed, 24 Oct 2007 15:25:57 -0400 Subject: [OpenAFS] Re: openafs.org downloads - Kerberos 5 or not? In-Reply-To: References: <471F95A2.70904@kickflop.net> Message-ID: <471F9C45.5060509@kickflop.net> Exactly what I needed to know. Thanks. > if the vendor provides krb5, we use it. if not, it's hard to know which > kerberos a site will use, so we don't. > > the simple test: does the vendor ship krb5? > > every linux. macos. starting in 1.4.5, aix 5 and opensolaris. From jaltman@secure-endpoints.com Wed Oct 24 20:31:11 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 24 Oct 2007 15:31:11 -0400 Subject: [OpenAFS] Using OpenAFS client with AFS Server 3.6 In-Reply-To: <13383657.post@talk.nabble.com> References: <13383657.post@talk.nabble.com> Message-ID: <471F9D7F.7000109@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms060507050900070201060006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Matthew1 wrote: > Hello, > > I am working on a project which wants to utilize the OpenAFS client to > connect to an AFS server running version 3.6. So far we have been unable to > find out if this will work ok. Can anyone provide information on this, and > perhaps direct us to where we can see the compatability of OpenAFS with > other AFS products? > > Thanks, > Matt OpenAFS is compatible with IBM AFS 3.6 servers provided that you restrict your client authentication to kaserver or Kerberos v4. --------------ms060507050900070201060006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjQxOTMxMTFaMCMGCSqGSIb3DQEJBDEWBBTggTBL g32WDZ9c1gFu1avs7JPdpDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEABspseMSu8/gmXFXG6cXIUVWrrTFj4d8iyDeBF0a7SVqFRXDHWzyk 6R3u9K6+FkLO2Zr2X7xuQ8YfpGgR6MM5vzbg1ykBMjCB0SvoQ5A+kZjYsUjL4UPs0igGUHzQ mj2a3qp9Y3MlUrFENOozkUvb292qD24kwK150VYqrlotlJTmTKmDJA75gQ4N0WdM+okV0S2K JJQWmsntMLyKtDRgqI6WC8GIsQ4KkN0Y72ZQa2kdagH9YlKnufUodNfpDpFWH4rvK+fiPcRA vesqpGpe5oXoYubCXsVHjG3ehP5hx3sKfalHnomldjT7f0DWrfK9ouszGnxXDw9c4Edyo+Zm LgAAAAAAAA== --------------ms060507050900070201060006-- From john@iastate.edu Wed Oct 24 20:47:44 2007 From: john@iastate.edu (John Hascall) Date: Wed, 24 Oct 2007 14:47:44 CDT Subject: [OpenAFS] Automatic move of volumes In-Reply-To: Your message of Wed, 24 Oct 2007 10:23:09 -0400. <471F554D.5030402@dartmouth.edu> Message-ID: <24857.1193255264@malison.ait.iastate.edu> > Steven Jenkins wrote: > > I hadn't really thought about people intentionally keeping their RWs & > > ROs out of sync w/each other. I'm not clear why someone would want to > > do that -- could you elaborate? > some examples: > - putting in a new version of some software, and and trying it out > before releasing it to the community > - having a well-known, scheduled time for releasing certain volumes > to ensure that files become available at an approximately-scheduled time > (useful for website management, or for dealing with vos releases of very > popular volumes typically near the top of an afs tree) I'm with Steve on this one. Deliberately depending on the desynchronization of an RO copy from its RW for any significant period of time seems like something that is going to bite you in the ass someday. John From Lars.Richter@prodesigncad.de Wed Oct 24 20:57:56 2007 From: Lars.Richter@prodesigncad.de (Lars Richter) Date: Wed, 24 Oct 2007 21:57:56 +0200 Subject: [OpenAFS] file timestamp difference In-Reply-To: <471F8A21.1020802@columbia.edu> References: <471F5017.8050203@prodesigncad.de> <20071024.164327.76527676.haba@habarber.pdc.kth.se> <471F65BA.6090509@prodesigncad.de> <471F8A21.1020802@columbia.edu> Message-ID: <471FA3C4.70402@prodesigncad.de> Hi, I test this patch tomorrow morning. Lars Jeffrey Altman schrieb: > Thread migrated from OpenAFS-Info to OpenAFS-Devel due to patch content. > > Can someone please test these patches? > > /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/linux26-nsec-1_4-1.patch > > /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/linux26-nsec-1_5-1.patch > > Thanks. > > Jeffrey Altman > > From jblaine@kickflop.net Wed Oct 24 21:34:16 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Wed, 24 Oct 2007 16:34:16 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? Message-ID: <471FAC48.3090004@kickflop.net> I realize there's not a conversion process to get AFS krb4 principal passwords into krb5-land. What approaches have you all taken in order to make the kaserver -> krb5 KDC transition as painless as possible to users? Thanks for any insight/tips. From mitch@ccmr.cornell.edu Wed Oct 24 21:43:54 2007 From: mitch@ccmr.cornell.edu (Mitch Collinsworth) Date: Wed, 24 Oct 2007 16:43:54 -0400 (EDT) Subject: [OpenAFS] Server upgrade time; which is the right way? In-Reply-To: <471FA3C4.70402@prodesigncad.de> References: <471F5017.8050203@prodesigncad.de> <20071024.164327.76527676.haba@habarber.pdc.kth.se> <471F65BA.6090509@prodesigncad.de> <471F8A21.1020802@columbia.edu> <471FA3C4.70402@prodesigncad.de> Message-ID: Greetings, We're planning an upgrade to all of our AFS servers sometime soon. We do this infrequently enough that it always makes us nervous. :-) As such we'd like to run a plan past the list to see if we're overlooking something, either obvious or not so obvious... All servers are currently running 1.2.13. We're planning to upgrade to 1.4.4. The current draft plan goes like this: 1. Take down the database servers one at a time and upgrade the OS and the OAFS binaries. 2. Take down the fileservers one at a time and upgrade either OS and OAFS or just OAFS as needed. There seems to be a conflict of opinions here on whether a rolling upgrade like this is either a) a non-issue, people do it all the time; or b) a huge mistake that will inflict serious pain and sleepless nights because everyone knows we should be taking everything down at once for a major version upgrade like this. Comments? -Mitch From allbery@ece.cmu.edu Wed Oct 24 22:12:59 2007 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed, 24 Oct 2007 17:12:59 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: On Oct 24, 2007, at 12:21 , Steven Jenkins wrote: > I think it would be very useful if someone had the time/energy to > build a 'vms-lite' that people could adopt at their sites. That seems > a more strategic direction than trying to extend RO capabilities. I have to admit I've thought about what would be involved in developing a ClearCase-like setup based on AFS (CC uses NFS with snapshots to implement "views"... and seems to inherit NFS's general lack of structure). At minimum it would require rather more complex relationships between R/O versions than AFS currently has (or has the ability to support without overhauling volume headers at minimum). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jaltman@secure-endpoints.com Wed Oct 24 22:16:04 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 24 Oct 2007 17:16:04 -0400 Subject: [OpenAFS] Server upgrade time; which is the right way? In-Reply-To: References: <471F5017.8050203@prodesigncad.de> <20071024.164327.76527676.haba@habarber.pdc.kth.se> <471F65BA.6090509@prodesigncad.de> <471F8A21.1020802@columbia.edu> <471FA3C4.70402@prodesigncad.de> Message-ID: <471FB614.20400@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms040201010909080801020200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mitch Collinsworth wrote: > > Greetings, > > We're planning an upgrade to all of our AFS servers sometime soon. > We do this infrequently enough that it always makes us nervous. :-) > As such we'd like to run a plan past the list to see if we're > overlooking something, either obvious or not so obvious... > > All servers are currently running 1.2.13. We're planning to upgrade > to 1.4.4. > > The current draft plan goes like this: > > 1. Take down the database servers one at a time and upgrade the OS and > the OAFS binaries. > > 2. Take down the fileservers one at a time and upgrade either OS and > OAFS or just OAFS as needed. > > There seems to be a conflict of opinions here on whether a rolling > upgrade like this is either a) a non-issue, people do it all the time; > or b) a huge mistake that will inflict serious pain and sleepless > nights because everyone knows we should be taking everything down at > once for a major version upgrade like this. My personal belief is that services that share databases should have all of the servers upgraded simultaneously. File servers on the other hand can be migrated one at a time. Add a new file server to the cell, migrate volumes, when an old file server is empty it can be decommissioned. Others with more operational experience may have other views. Jeffrey Altman --------------ms040201010909080801020200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjQyMTE2MDRaMCMGCSqGSIb3DQEJBDEWBBT7nP19 kjg2FRxG2094m0j2VHfUTzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAHYYu6pKVCtdrJzrgdHHVQwJ/JH/sDBTINUtXsI64i4nglh6uWGrK 8u/xU4qtEWGalbNiDG15/0uOKtdDqLk+ibfZ84dh2CXEdbCHizATU4KDMvn5g6p1WmBAkMqh g/4ePAqHAFzAQMdjV11lBJjiOV7VYqpMOyOWyC0LyEtMsrJlAIoIDsfNDuFBj96ntMupGTVL EKqt2Jnie+li9t8Xs3aZb6hGhYNGwFnXwFnc9irxAHcJAH48AIzLteGrtQ2pWblco9rQdsew MxOrHmWmild3M9PuTxt8+X3LMJ4c8+TxY/9ONNv9hGu+A2hGwdZZZUp9XDps8y9b21TphSgf wQAAAAAAAA== --------------ms040201010909080801020200-- From alfw@slac.stanford.edu Wed Oct 24 22:23:43 2007 From: alfw@slac.stanford.edu (Alf Wachsmann) Date: Wed, 24 Oct 2007 14:23:43 -0700 (PDT) Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <471FAC48.3090004@kickflop.net> References: <471FAC48.3090004@kickflop.net> Message-ID: On Wed, 24 Oct 2007, Jeff Blaine wrote: > I realize there's not a conversion process to get AFS krb4 > principal passwords into krb5-land. > > What approaches have you all taken in order to make the > kaserver -> krb5 KDC transition as painless as possible > to users? Jeff, Heimdal has an easy way of importing a kaserver DB into its K5 KDC. It can also read MIT K5 KDC DB dumps. Not sure whether MIT K5 can do any of this. -- Alf. ----------------------------------------------------------------------- Alf Wachsmann | e-mail: alfw@slac.stanford.edu SLAC - Scientific Computing | Phone: +1-650-926-4802 2575 Sand Hill Road, M/S 97 | FAX: +1-650-926-3329 Menlo Park, CA 94025, USA | Office: Bldg. 50/323 ----------------------------------------------------------------------- http://www.slac.stanford.edu/~alfw (PGP) ----------------------------------------------------------------------- From mike@pictage.com Thu Oct 25 00:36:19 2007 From: mike@pictage.com (Mike Polek) Date: Wed, 24 Oct 2007 16:36:19 -0700 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> References: <200710241351.l9ODpg3L023000@cmf.nrl.navy.mil> Message-ID: <471FD6F3.3070900@pictage.com> I wrote a couple perl script some time ago to move volumes between servers. It uses the AFS::VOS perl interface, and it handles RO volumes. It doesn't take into account purposely unreleased volumes, as we don't really do that here. (We use the backup volume at times for previews and such, but we try to keep the RW and RO in sync at all times.) I don't think it handles the issue where there is already a RO on the target either. Our cell is organized so that wouldn't really happen. It uses a support script that attempts to distribute the volumes evenly between the destination servers/partitions. If you would like a copy, contact me off list. Or if there is sufficient interest, I can publish to the list. I don't know how many people besides us use the perl interface. Thanks, Mike chas williams - CONTRACTOR wrote: > In message <1193225691.11351.34.camel@thor>,Jacob Volstrup writes: > >>For quite some time I've been searching for something to help me move >>some volumes from a constantly failing /vicepa raid to my new /vicepb. >>The reason for not doing this manually is partly that I'm lazy and >>Further, I would like to have this fully automated if I would like to >>move them back in the future (perhaps when the disks for /vicepa are >>replaced). > > > i wrote this a while back when i was migrating file servers. it takes > 4 arguments, , > and optionally the -ro flag to also move the read-only's. > > it generates a list of commands that you typically run with /bin/sh (or > you could just pipe to sh), so if you want to revert your actions at a > later save this as a script and do a little sed magic on it to reverse > the actions. > > it doesnt deal with the duplicate readonly problems. that wouldnt be > hard to add or you could just live with the errors. > -- Mike Polek Pictage, Inc. From sdevine@msu.edu Thu Oct 25 02:13:08 2007 From: sdevine@msu.edu (Steve Devine) Date: Wed, 24 Oct 2007 21:13:08 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <471FAC48.3090004@kickflop.net> References: <471FAC48.3090004@kickflop.net> Message-ID: <471FEDA4.3030406@msu.edu> Jeff Blaine wrote: > I realize there's not a conversion process to get AFS krb4 > principal passwords into krb5-land. > > What approaches have you all taken in order to make the > kaserver -> krb5 KDC transition as painless as possible > to users? > > Thanks for any insight/tips. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info This is not so. From my notes : *********************************** afs2k5db /usr/afs/db/kaserver.DB0 >all.out then edit the all.out file: Remove line for AuthServer , krbtgt, and afs Be sure and leave in first line ( kdb5_util load_dump version 4) Then load em all in. kdb5_util load -update all.out (Leave verbose switch out it will just slow you down.) ******************************** -- Steve Devine Network Storage and Printing Academic Computing & Network Services Michigan State University 506 Computer Center East Lansing, MI 48824-1042 1-517-432-7327 Baseball is ninety percent mental; the other half is physical. - Yogi Berra From haba@kth.se Thu Oct 25 08:02:15 2007 From: haba@kth.se (Harald Barth) Date: Thu, 25 Oct 2007 09:02:15 +0200 (MEST) Subject: [OpenAFS] Server upgrade time; which is the right way? In-Reply-To: References: <471F8A21.1020802@columbia.edu> <471FA3C4.70402@prodesigncad.de> Message-ID: <20071025.090215.98471013.haba@habarber.pdc.kth.se> > There seems to be a conflict of opinions here on whether a rolling > upgrade like this is either a) a non-issue, people do it all the time; > or b) a huge mistake that will inflict serious pain and sleepless > nights because everyone knows we should be taking everything down at > once for a major version upgrade like this. If different database server versions would generate pain, I would had to do something about the following a long time ago... $ /usr/openafs/sbin/rxdebug anna 7003 -v Trying 130.237.232.112 (port 7003): AFS version: OpenAFS 1.4.0 built 2005-11-15 $ /usr/openafs/sbin/rxdebug hokkigai 7003 -v Trying 130.237.232.114 (port 7003): AFS version: OpenAFS 1.2.11 built 2004-01-12 $ /usr/openafs/sbin/rxdebug crab 7003 -v Trying 130.237.232.29 (port 7003): AFS version: OpenAFS 1.4.2 built 2006-11-09 I vaguely remember a "take everything down" scenario necessary many many years ago. Harald. From Lars.Richter@prodesigncad.de Thu Oct 25 10:16:31 2007 From: Lars.Richter@prodesigncad.de (Lars Richter) Date: Thu, 25 Oct 2007 11:16:31 +0200 Subject: [OpenAFS] file timestamp difference In-Reply-To: <471FA3C4.70402@prodesigncad.de> References: <471F5017.8050203@prodesigncad.de> <20071024.164327.76527676.haba@habarber.pdc.kth.se> <471F65BA.6090509@prodesigncad.de> <471F8A21.1020802@columbia.edu> <471FA3C4.70402@prodesigncad.de> Message-ID: <47205EEF.5090405@prodesigncad.de> Hi, I applied this patch to version 1.4.4. Recompiled the sources and changed the kernel module to the new one. It seems ok! At the client the time is shown with nanoseconds set to zero= . Is it right, that I have to update all clients? Regards, Lars Lars Richter schrieb: > Hi, > > I test this patch tomorrow morning. > > Lars > > Jeffrey Altman schrieb: >> Thread migrated from OpenAFS-Info to OpenAFS-Devel due to patch conten= t. >> >> Can someone please test these patches? >> >> /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/linux26-nsec-1_4-1= .patch >> >> >> /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/linux26-nsec-1_5-1= .patch >> >> >> Thanks. >> >> Jeffrey Altman >> >> =20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --=20 Dipl.-Inf. Lars Richter Pro Design Electronic GmbH Europaplatz 5, 99091 Erfurt phone: +49 361 55038-25 fax: +49 361 78930-80 www.prodesigncad.de Vertretungsberechtigte Gesch=E4ftsf=FChrer: Helmut Mahr, Ulrike Angersbach, Stephan R=F6slmair, Heiko Mauersberger Registergericht: Amtsgericht Traunstein Registernummer: HRB 13 002=20 From jblaine@kickflop.net Thu Oct 25 15:53:28 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Thu, 25 Oct 2007 10:53:28 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <471FEDA4.3030406@msu.edu> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> Message-ID: <4720ADE8.5030003@kickflop.net> Steve Devine wrote: > Jeff Blaine wrote: >> I realize there's not a conversion process to get AFS krb4 >> principal passwords into krb5-land. >> >> What approaches have you all taken in order to make the >> kaserver -> krb5 KDC transition as painless as possible >> to users? >> >> Thanks for any insight/tips. > This is not so. > From my notes : > *********************************** > afs2k5db /usr/afs/db/kaserver.DB0 >all.out > then edit the all.out file: > Remove line for AuthServer , krbtgt, and afs > Be sure and leave in first line ( kdb5_util load_dump version 4) > Then load em all in. > kdb5_util load -update all.out > (Leave verbose switch out it will just slow you down.) > ******************************** I assume that's a Heimdal installation? I should have clarified in the original post: MIT Kerberos. Or is everyone using Heimdal with OpenAFS? From sdevine@msu.edu Thu Oct 25 15:59:31 2007 From: sdevine@msu.edu (Steve Devine) Date: Thu, 25 Oct 2007 10:59:31 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720ADE8.5030003@kickflop.net> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> Message-ID: <4720AF53.7040308@msu.edu> Jeff Blaine wrote: > Steve Devine wrote: >> Jeff Blaine wrote: >>> I realize there's not a conversion process to get AFS krb4 >>> principal passwords into krb5-land. >>> >>> What approaches have you all taken in order to make the >>> kaserver -> krb5 KDC transition as painless as possible >>> to users? >>> >>> Thanks for any insight/tips. >> This is not so. >> From my notes : >> *********************************** >> afs2k5db /usr/afs/db/kaserver.DB0 >all.out >> then edit the all.out file: >> Remove line for AuthServer , krbtgt, and afs >> Be sure and leave in first line ( kdb5_util load_dump version 4) >> Then load em all in. >> kdb5_util load -update all.out >> (Leave verbose switch out it will just slow you down.) >> ******************************** > > I assume that's a Heimdal installation? No we are using MIT kerberos. > > I should have clarified in the original post: MIT Kerberos. > > Or is everyone using Heimdal with OpenAFS? > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Steve Devine Network Storage & Printing Academic Computing & Network Services Michigan State University 506 Computer Center East Lansing, MI 48824-1042 1-517-432-7327 Baseball is ninety percent mental; the other half is physical. - Yogi Berra From jaltman@secure-endpoints.com Thu Oct 25 16:06:08 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 11:06:08 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720ADE8.5030003@kickflop.net> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> Message-ID: <4720B0E0.7000203@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms090700070207040408070205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeff Blaine wrote: >> From my notes : >> *********************************** >> afs2k5db /usr/afs/db/kaserver.DB0 >all.out >> then edit the all.out file: >> Remove line for AuthServer , krbtgt, and afs >> Be sure and leave in first line ( kdb5_util load_dump version 4) >> Then load em all in. >> kdb5_util load -update all.out >> (Leave verbose switch out it will just slow you down.) >> ******************************** > > I assume that's a Heimdal installation? > > I should have clarified in the original post: MIT Kerberos. afs2k5db converts to the MIT Kerberos dump file format. --------------ms090700070207040408070205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxNTA2MDlaMCMGCSqGSIb3DQEJBDEWBBS4anuN GD8LHjdoNgk5Mu4vhm5xojBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAnAft1bfPDuZIGgLzlL46ERMjRurNKxE+tyqFlgQN+PB19K0enfAo /1s7lYcXzVPtdrWzDpaNmgstksLDQyanq/Zw8L7ttbSuj1D4el2sS58YktoS1wcmYEau3Of9 HCUZRwp4+Jq5RF6eR15bgsu2ee/ORwcePa3B+aUo9kB09AGl3kiDFUl4n5eK1HazYGmV1V0M xPz3EpnyQ/42v424vmx3LXw/QzOmHgW3ZT1+bU3A7NP6mUtIfyH+TlBf5eT+tJ8/0oLRQ8C2 RhJsA3yQ5oGonGNCP8y+1qn1oMvteB/hSxzbbiK50gIAH0QLhahoeyEhsP1PbtxT/36tDEWA kAAAAAAAAA== --------------ms090700070207040408070205-- From sdevine@msu.edu Thu Oct 25 16:08:17 2007 From: sdevine@msu.edu (Steve Devine) Date: Thu, 25 Oct 2007 11:08:17 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720AF53.7040308@msu.edu> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> Message-ID: <4720B161.6040707@msu.edu> Steve Devine wrote: > Jeff Blaine wrote: >> Steve Devine wrote: >>> Jeff Blaine wrote: >>>> I realize there's not a conversion process to get AFS krb4 >>>> principal passwords into krb5-land. >>>> >>>> What approaches have you all taken in order to make the >>>> kaserver -> krb5 KDC transition as painless as possible >>>> to users? >>>> >>>> Thanks for any insight/tips. >>> This is not so. >>> From my notes : >>> *********************************** >>> afs2k5db /usr/afs/db/kaserver.DB0 >all.out >>> then edit the all.out file: >>> Remove line for AuthServer , krbtgt, and afs >>> Be sure and leave in first line ( kdb5_util load_dump version 4) >>> Then load em all in. >>> kdb5_util load -update all.out >>> (Leave verbose switch out it will just slow you down.) >>> ******************************** >> >> I assume that's a Heimdal installation? > No we are using MIT kerberos. >> >> I should have clarified in the original post: MIT Kerberos. >> >> Or is everyone using Heimdal with OpenAFS? >> >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info > > Sorry I forgot this doesn't come with Mit Kerberos .. you need to get afs-krb5 and build it against your kerberos libs. Google is your friend. /sd -- Steve Devine Network Storage & Printing Academic Computing & Network Services Michigan State University 506 Computer Center East Lansing, MI 48824-1042 1-517-432-7327 Baseball is ninety percent mental; the other half is physical. - Yogi Berra From jblaine@kickflop.net Thu Oct 25 16:28:33 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Thu, 25 Oct 2007 11:28:33 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720B161.6040707@msu.edu> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> <4720B161.6040707@msu.edu> Message-ID: <4720B621.6030001@kickflop.net> You had me wondering. The only reference to afs2k5db I could find in source was src/packaging/RedHat/openafs.spec.in Which then leads me to: Are the RedHat builds getting preferential treatment with regard to this? Is there a reason? What's up? Steve Devine wrote: > Steve Devine wrote: >> Jeff Blaine wrote: >>> Steve Devine wrote: >>>> Jeff Blaine wrote: >>>>> I realize there's not a conversion process to get AFS krb4 >>>>> principal passwords into krb5-land. >>>>> >>>>> What approaches have you all taken in order to make the >>>>> kaserver -> krb5 KDC transition as painless as possible >>>>> to users? >>>>> >>>>> Thanks for any insight/tips. >>>> This is not so. >>>> From my notes : >>>> *********************************** >>>> afs2k5db /usr/afs/db/kaserver.DB0 >all.out >>>> then edit the all.out file: >>>> Remove line for AuthServer , krbtgt, and afs >>>> Be sure and leave in first line ( kdb5_util load_dump version 4) >>>> Then load em all in. >>>> kdb5_util load -update all.out >>>> (Leave verbose switch out it will just slow you down.) >>>> ******************************** >>> >>> I assume that's a Heimdal installation? >> No we are using MIT kerberos. >>> >>> I should have clarified in the original post: MIT Kerberos. >>> >>> Or is everyone using Heimdal with OpenAFS? >>> >>> _______________________________________________ >>> OpenAFS-info mailing list >>> OpenAFS-info@openafs.org >>> https://lists.openafs.org/mailman/listinfo/openafs-info >> >> > Sorry I forgot this doesn't come with Mit Kerberos .. you need to get > > afs-krb5 and build it against your kerberos libs. > Google is your friend. > /sd > > From cclausen@acm.org Thu Oct 25 16:43:13 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Thu, 25 Oct 2007 10:43:13 -0500 Subject: [OpenAFS] Password transition to krb5 - your methods? References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> <4720B161.6040707@msu.edu> <4720B621.6030001@kickflop.net> Message-ID: <72CE2D26539A428EAD82075F226E67D5@CDCHOME> Jeff Blaine wrote: > You had me wondering. > > The only reference to afs2k5db I could find in source was > > src/packaging/RedHat/openafs.spec.in > > Which then leads me to: > > Are the RedHat builds getting preferential treatment with > regard to this? Is there a reason? What's up? I think you want the afs krb5 migration kit: ftp://ftp.cmf.nrl.navy.mil/pub/kerberos5/afs-krb5-2.0.tar.gz Is that the most up to date version? < References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> <4720B161.6040707@msu.edu> <4720B621.6030001@kickflop.net> Message-ID: ------=_Part_1716_30688359.1193327171004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/25/07, Jeff Blaine wrote: > > You had me wondering. > > The only reference to afs2k5db I could find in source was > > src/packaging/RedHat/openafs.spec.in > > Which then leads me to: > > Are the RedHat builds getting preferential treatment with > regard to this? Is there a reason? What's up? in the sense that warlord made the rpms ship the entire afs-krb5 kit, and no other set of packages does, yes. technically that wasn't part of openafs. i think it's in 1.4.5 now though. this is the "problem" with all-volunteer projects. consistency is overrated. ------=_Part_1716_30688359.1193327171004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/25/07, Jeff Blaine <jblaine@kickflop.net> wrote:
You had me wondering.

The only reference to afs2k5db I could find in source was

     src/packaging/RedHat/openafs.spec.in

Which then leads me to:

Are the RedHat builds getting preferential treatment with
regard to this?  Is there a reason?  What's up?

in the sense that warlord made the rpms ship the entire afs-krb5 kit, and no other set of packages does, yes.
technically that wasn't part of openafs. i think it's in 1.4.5 now though.

this is the "problem" with all-volunteer projects.

consistency is overrated.

 


------=_Part_1716_30688359.1193327171004-- From jaltman@secure-endpoints.com Thu Oct 25 16:56:44 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 11:56:44 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> <4720B161.6040707@msu.edu> <4720B621.6030001@kickflop.net> Message-ID: <4720BCBC.7020009@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms050604050607030500020003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Derrick Brashear wrote: > > > On 10/25/07, *Jeff Blaine* > wrote: > > You had me wondering. > > The only reference to afs2k5db I could find in source was > > src/packaging/RedHat/openafs.spec.in > > Which then leads me to: > > Are the RedHat builds getting preferential treatment with > regard to this? Is there a reason? What's up? > > > in the sense that warlord made the rpms ship the entire afs-krb5 kit, > and no other set of packages does, yes. > technically that wasn't part of openafs. i think it's in 1.4.5 now though. afs2k5db is not part of openafs 1.4.5. Building it requires access to private MIT krb5 headers. We would distribute it if we could build it using the public headers but we can't. Jeffrey Altman --------------ms050604050607030500020003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxNTU2NDRaMCMGCSqGSIb3DQEJBDEWBBQfLIkn 3tt6uUscPTJmQQ/cZ65FSDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAOx1Djl0l5hjr9z/fbiciYQj8Vv/iN+7FTM+ygvGpPms+nzUz5Igr nEQJ+qNTZRmwKTGA2khbU+IKPixPFwIZY01sE9SXIqta0hHBl9d3N5YGMaNFnohy/tI+QAvZ yMTwHLBzfr2Dkl7ZCVOIMstmQtofnO7EAcnxsIyQLPGhZbtT7N891FvnvcjgRQwm0JwgaRN4 AaBvju6VLLsWo97bCKap6E4YJKwFc9Ezqw2ETYDfaSBrires1qALbI9t+crVoxBcZ13tinzl OOYobiTI7zGrBS9IyH648zDpJIgcwMtJLvdAVbUS2J3avTPoczhqCuX6GTEHGqlVWMJCXMxk tgAAAAAAAA== --------------ms050604050607030500020003-- From jblaine@kickflop.net Thu Oct 25 17:06:47 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Thu, 25 Oct 2007 12:06:47 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720BCBC.7020009@secure-endpoints.com> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> <4720B161.6040707@msu.edu> <4720B621.6030001@kickflop.net> <4720BCBC.7020009@secure-endpoints.com> Message-ID: <4720BF17.6090302@kickflop.net> IMO, it should be distributed with it and referenced in a new README.kaserver (which also should include the elders EOL statement regarding kaserver). It doesn't have to be referenced by the build process. I wouldn't surprise me to find that nobody agrees with me again. Jeffrey Altman wrote: > Derrick Brashear wrote: >> >> On 10/25/07, *Jeff Blaine* > > wrote: >> >> You had me wondering. >> >> The only reference to afs2k5db I could find in source was >> >> src/packaging/RedHat/openafs.spec.in >> >> Which then leads me to: >> >> Are the RedHat builds getting preferential treatment with >> regard to this? Is there a reason? What's up? >> >> >> in the sense that warlord made the rpms ship the entire afs-krb5 kit, >> and no other set of packages does, yes. >> technically that wasn't part of openafs. i think it's in 1.4.5 now though. > > afs2k5db is not part of openafs 1.4.5. Building it requires access to > private MIT krb5 headers. We would distribute it if we could build it > using the public headers but we can't. > > Jeffrey Altman > > From jason@rampaginggeek.com Thu Oct 25 17:06:07 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Thu, 25 Oct 2007 12:06:07 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720ADE8.5030003@kickflop.net> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> Message-ID: <4720BEEF.5040206@rampaginggeek.com> Jeff Blaine wrote: > Steve Devine wrote: >> Jeff Blaine wrote: >>> I realize there's not a conversion process to get AFS krb4 >>> principal passwords into krb5-land. >>> >>> What approaches have you all taken in order to make the >>> kaserver -> krb5 KDC transition as painless as possible >>> to users? >>> >>> Thanks for any insight/tips. >> This is not so. >> From my notes : >> *********************************** >> afs2k5db /usr/afs/db/kaserver.DB0 >all.out >> then edit the all.out file: >> Remove line for AuthServer , krbtgt, and afs >> Be sure and leave in first line ( kdb5_util load_dump version 4) >> Then load em all in. >> kdb5_util load -update all.out >> (Leave verbose switch out it will just slow you down.) >> ******************************** > > I assume that's a Heimdal installation? > > I should have clarified in the original post: MIT Kerberos. > > Or is everyone using Heimdal with OpenAFS? The UNCC.EDU cell is using MIT kerberos 5. We disabled kaserver during the summer and we just removed the service last week. Jason From jaltman@secure-endpoints.com Thu Oct 25 17:11:08 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 12:11:08 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720BCBC.7020009@secure-endpoints.com> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> <4720B161.6040707@msu.edu> <4720B621.6030001@kickflop.net> <4720BCBC.7020009@secure-endpoints.com> Message-ID: <4720C01C.8080101@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms040005040500000805070304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeffrey Altman wrote: > afs2k5db is not part of openafs 1.4.5. Building it requires access to > private MIT krb5 headers. We would distribute it if we could build it > using the public headers but we can't. I will also point out that you should build it against MIT Kerberos 1.2, 1.3, or 1.4. Don't waste your time trying to get it to build against something newer. If you can find a binary that someone else has already built, use it. Jeffrey Altman --------------ms040005040500000805070304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxNjExMDhaMCMGCSqGSIb3DQEJBDEWBBR+Th7U RA4TGuXa7iH45K7BT0DYXTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAoY7gPNsLDZSiKdm6TrmSj4IHGXClYBcoOhO7tV8XTcLaJEsrLPrj B+lXX1rJW9BU/37gl99rAJeFrL+rHe94Fkfvqsuq3d9LpaF1j0q6u8JytTGb+0v8gv4IKLGW Bj1pQrrmP8jzGPY66bP1JZ2n6mnyOwOppQVMBqWE5naZs/QkdVdsaZhsvMs+d9MasbAf5wVq P65XNzSowXsi2aOjzflqzJtSEN+3xCroFK+XMJFNpcBbtappLm+Topu2bFFJ7RWNZ3wJaOw5 vJ8VRgZ+o5NAXSUAovXh6UZRNx6467farYV9qR5xYxOsw0oV3pR+iLOm93e45chnmEyaRLr7 vgAAAAAAAA== --------------ms040005040500000805070304-- From shadow@gmail.com Thu Oct 25 17:11:26 2007 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 25 Oct 2007 12:11:26 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720BF17.6090302@kickflop.net> References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> <4720B161.6040707@msu.edu> <4720B621.6030001@kickflop.net> <4720BCBC.7020009@secure-endpoints.com> <4720BF17.6090302@kickflop.net> Message-ID: ------=_Part_1815_9375091.1193328686821 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline i disagree about distribution. i do think we should have a page with instructions and resources we provide a reference to. On 10/25/07, Jeff Blaine wrote: > > IMO, it should be distributed with it and referenced > in a new README.kaserver (which also should include > the elders EOL statement regarding kaserver). > > It doesn't have to be referenced by the build process. > > I wouldn't surprise me to find that nobody agrees with > me again. > > Jeffrey Altman wrote: > > Derrick Brashear wrote: > >> > >> On 10/25/07, *Jeff Blaine* >> > wrote: > >> > >> You had me wondering. > >> > >> The only reference to afs2k5db I could find in source was > >> > >> src/packaging/RedHat/openafs.spec.in > >> > >> Which then leads me to: > >> > >> Are the RedHat builds getting preferential treatment with > >> regard to this? Is there a reason? What's up? > >> > >> > >> in the sense that warlord made the rpms ship the entire afs-krb5 kit, > >> and no other set of packages does, yes. > >> technically that wasn't part of openafs. i think it's in 1.4.5 now > though. > > > > afs2k5db is not part of openafs 1.4.5. Building it requires access to > > private MIT krb5 headers. We would distribute it if we could build it > > using the public headers but we can't. > > > > Jeffrey Altman > > > > > ------=_Part_1815_9375091.1193328686821 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline i disagree about distribution. i do think we should have a page with instructions and resources we provide a reference to.

On 10/25/07, Jeff Blaine < jblaine@kickflop.net> wrote:
IMO, it should be distributed with it and referenced
in a new README.kaserver (which also should include
the elders EOL statement regarding kaserver).

It doesn't have to be referenced by the build process.

I wouldn't surprise me to find that nobody agrees with
me again.

Jeffrey Altman wrote:
> Derrick Brashear wrote:
>>
>> On 10/25/07, *Jeff Blaine* <jblaine@kickflop.net
>> <mailto: jblaine@kickflop.net>> wrote:
>>
>>     You had me wondering.
>>
>>     The only reference to afs2k5db I could find in source was
>>
>>          src/packaging/RedHat/openafs.spec.in
>>
>>     Which then leads me to:
>>
>>     Are the RedHat builds getting preferential treatment with
>>     regard to this?  Is there a reason?  What's up?
>>
>>
>> in the sense that warlord made the rpms ship the entire afs-krb5 kit,
>> and no other set of packages does, yes.
>> technically that wasn't part of openafs. i think it's in 1.4.5 now though.
>
> afs2k5db is not part of openafs 1.4.5.  Building it requires access to
> private MIT krb5 headers.  We would distribute it if we could build it
> using the public headers but we can't.
>
> Jeffrey Altman
>
>

------=_Part_1815_9375091.1193328686821-- From jaltman@secure-endpoints.com Thu Oct 25 17:40:39 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 12:40:39 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: References: <471FAC48.3090004@kickflop.net> <471FEDA4.3030406@msu.edu> <4720ADE8.5030003@kickflop.net> <4720AF53.7040308@msu.edu> <4720B161.6040707@msu.edu> <4720B621.6030001@kickflop.net> <4720BCBC.7020009@secure-endpoints.com> <4720BF17.6090302@kickflop.net> Message-ID: <4720C707.20802@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms070300020500010403090103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Derrick Brashear wrote: > i disagree about distribution. i do think we should have a page with > instructions and resources we provide a reference to. > > On 10/25/07, *Jeff Blaine* < jblaine@kickflop.net > > wrote: > > IMO, it should be distributed with it and referenced > in a new README.kaserver (which also should include > the elders EOL statement regarding kaserver). > > It doesn't have to be referenced by the build process. > > I wouldn't surprise me to find that nobody agrees with > me again. I agree that it is stupid at this point for administrators to be forced to track down the remnants of Ken Hornstein's afs2krb5 migration kit in order to obtain the one missing piece that is neither distributed with OpenAFS or MIT Kerberos. Given that the afs2k5db tool is a Kerberos tool that requires explicit access to internal Kerberos data structures. I would argue that it really should be distributed as part of MIT Kerberos much as fakeka is distributed as part of MIT Kerberos. The point of the tool is to help you migrate your KDC to MIT's KDC. Making it easier to do so should be a job of each Kerberos distribution. Since MIT won't ship it, we should provide a pointer to the remaining sources. It would be nice if someone would extract the necessary pieces from the afs-krb5 kit and repackage it. Perhaps even port it to more recent versions of MIT Kerberos. Then OpenAFS can provide a pointer to it. Jeffrey Altman --------------ms070300020500010403090103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxNjQwMzlaMCMGCSqGSIb3DQEJBDEWBBR+0WXX EyiPRz57GDw6UjHBuK0HfDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAl6T6xPnZsp8nclsAPFJkJj/Eo3OnwG2DItLXm5Je+lC3ukApq9gR Mjtj3EqZcOJr674W18Fp6+mnnb5vQ8dICg00C4OF+n/2D9ycMf3v6El8LZMX+o78/+24qjy/ zW3tmLPVYh3cER5L+2XYbbZr9GgDWB3iVReIV+2IwVAC6ijLjNfz3babiF7ezH0ThnDw1JvD RdJJyTv5cf3DPXIo11AOafamceGOnQi36rlA0K817B6tc/lCt+x0rr1ucMtM2VZ1B/JHaeXV LmeXZfE7+9dUGzPe86sgwkJnQlnggZ54FPWqmWQD2VmuoZ0enSMv+8rKHgmcEgESq8Qhqmcv 3wAAAAAAAA== --------------ms070300020500010403090103-- From kenh@cmf.nrl.navy.mil Thu Oct 25 17:36:28 2007 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Thu, 25 Oct 2007 12:36:28 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720BF17.6090302@kickflop.net> Message-ID: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> >IMO, it should be distributed with it and referenced >in a new README.kaserver (which also should include >the elders EOL statement regarding kaserver). > >It doesn't have to be referenced by the build process. > >I wouldn't surprise me to find that nobody agrees with >me again. Sigh. Jeff, I got your private email about problems building afs2k5db; I'm going to reply to this note and consider it a reply to your private note as well, because they're related. afs2k5db doesn't have a home, as you've discovered. So it's not a case of Redhat getting preferential treatment; the people who put the Redhat package together did extra work to put it in there. Why doesn't it have a home? Well, it is unfortunately an odd program. What afs2k5db needs to do is know about AFS internals (the format of the kaserver database) _and_ MIT Kerberos internals (the necessary magic to read a stash file or handle the master key, and output Kerberos dump file formats). When splitting up the various parts of the AFS-Kerberos 5 migration kit, the MIT Kerberos people said that "things that act like a KDC" (such as fakeka) they felt were better suited to ship with MIT Kerberos. Utilities such as aklog and asetkey are pretty obviously mostly AFS utilities that happen to link against Kerberos libraries and use Kerberos public APIs, so it makes sense to put them in OpenAFS. However ... no one was really sure what to do with afs2k5db. The MIT Kerberos people didn't want it, and the OpenAFS people understandably didn't want to ship with something that required private header files and functions and was almost certainly going to break in future MIT Kerberos releases. So that's the situation we're in now, to provide some history. Now, what SHOULD we do? Well, if it was up to me, I think afs2k5db should be rewritten to use only public krb5 API functions and manually do all of the encoding necessary to create dump file records (most of that is there; you would need to parse the stash file and encrypt the principal keys yourself, but that isn't terrible). Since MIT Kerberos generally supports older dump file formats this would be reasonably future-proof. If this was done, I think it would be reasonable to ship this program with OpenAFS. But the problem here is I don't see who is going to do the work; obviously I transitioned our cell years ago, and I have no motivation or time to do work on fixing up afs2k5db. I think most other people are in a similar situation. While I regret that we're where we are now, that's the situation as I see it. Unfortunately that isn't much help to you. Regarding your specific compilation problem, Jeff ... looks like to me that swapping the order of the includes of k5-int.h and krb5.h would be a good first step. But like Jeff Altman already told you, newer versions of Kerberos are unlikely to work with it. --Ken From allbery@ece.cmu.edu Thu Oct 25 17:48:45 2007 From: allbery@ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu, 25 Oct 2007 12:48:45 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> References: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> Message-ID: On Oct 25, 2007, at 12:36 , Ken Hornstein wrote: > would be reasonable to ship this program with OpenAFS. But the > problem here is I don't see who is going to do the work; obviously > I transitioned our cell years ago, and I have no motivation or time > to do work on fixing up afs2k5db. I think most other people are > in a similar situation. While I regret that we're where we are > now, that's the situation as I see it. Unfortunately that isn't > much help to you. *half-facetiously wonders if it'd be easier to convince Love to unbundle hprop* -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jaltman@secure-endpoints.com Thu Oct 25 17:53:42 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 12:53:42 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> References: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> Message-ID: <4720CA16.2020401@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms020901080907040904070104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > Why doesn't it have a home? Well, it is unfortunately an odd program. > What afs2k5db needs to do is know about AFS internals (the format of the > kaserver database) _and_ MIT Kerberos internals (the necessary magic to > read a stash file or handle the master key, and output Kerberos dump > file formats). > > Now, what SHOULD we do? Well, if it was up to me, I think afs2k5db > should be rewritten to use only public krb5 API functions and > manually do all of the encoding necessary to create dump file records > (most of that is there; you would need to parse the stash file and > encrypt the principal keys yourself, but that isn't terrible). > Since MIT Kerberos generally supports older dump file formats this > would be reasonably future-proof. If this was done, I think it > would be reasonable to ship this program with OpenAFS. The MIT License is compatible with OpenAFS. Someone could simply copy the necessary routines out of MIT Kerberos and build a package that doesn't require MIT Kerberos at all. Or the inverse could be done. The kaserver database routines could be extracted and added to a tool that could be built by MIT without AFS being present. Since MIT already has all of the crypto library functions necessary, going in this direction might be less work. Jeffrey Altman --------------ms020901080907040904070104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxNjUzNDJaMCMGCSqGSIb3DQEJBDEWBBQbZw6h e6A0oYGdiKwLG4iHQKASSjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAj2XARDTccszJhEW4bqiB3mdZF6JeQdkPEUfq14Hk2ZERv4eYl3j/ KkZduo+9DyD7lvsmvfobHoXn/lTbKRtkrL9imrspgg4XGiohU/JCrkrEh1Ywxpd5PGv/kiJ2 HUKiOksy7GDGo/FWI9bPaZQS7bXnOiLYupvi/VGHHRfWhBgiIQVJI5jO/PjcQk/bmQI9mIY4 PPkui7ejeWuuGKwR2rJ58pXTnUlcOUTO6+wD1+yuXH1DATRry9znVfB+8ZmSvRi9oTROSVKt vl8p9+xNAGON8+kjNNw1rZK+i20/XvCa5f7SZ4aMCD+I+oRdKc8uYlUuQGlmPcrxhbgh6cAv EQAAAAAAAA== --------------ms020901080907040904070104-- From jblaine@kickflop.net Thu Oct 25 17:50:06 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Thu, 25 Oct 2007 12:50:06 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> References: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> Message-ID: <4720C93E.2060304@kickflop.net> Thank you for the usual thorough response, Ken. It's very welcome... and a bit amazing that you can construct a response that thorough and clear in ~20 minutes :) So my best bet, today, is to track down an MIT 1.3.0 release to build afs2k5db against then? Which is the next hurdle: http://web.mit.edu/Kerberos/historical.html -> http://web.mit.edu/Kerberos/krb5-1.3/krb5-1.3.html -> "Retrieve it here!" http://web.mit.edu/network/kerberos-form.html -> "The kerberos...blahblah has moved." Redirected in 1 second to main/modern dist. download page. Off to the Kerberos list I go. Ken Hornstein wrote: >> IMO, it should be distributed with it and referenced >> in a new README.kaserver (which also should include >> the elders EOL statement regarding kaserver). >> >> It doesn't have to be referenced by the build process. >> >> I wouldn't surprise me to find that nobody agrees with >> me again. > > Sigh. Jeff, I got your private email about problems building afs2k5db; > I'm going to reply to this note and consider it a reply to your private > note as well, because they're related. > > afs2k5db doesn't have a home, as you've discovered. So it's not a case of > Redhat getting preferential treatment; the people who put the Redhat > package together did extra work to put it in there. > > Why doesn't it have a home? Well, it is unfortunately an odd program. > What afs2k5db needs to do is know about AFS internals (the format of the > kaserver database) _and_ MIT Kerberos internals (the necessary magic to > read a stash file or handle the master key, and output Kerberos dump > file formats). > > When splitting up the various parts of the AFS-Kerberos 5 migration kit, > the MIT Kerberos people said that "things that act like a KDC" (such as > fakeka) they felt were better suited to ship with MIT Kerberos. Utilities > such as aklog and asetkey are pretty obviously mostly AFS utilities that > happen to link against Kerberos libraries and use Kerberos public APIs, > so it makes sense to put them in OpenAFS. However ... no one was really > sure what to do with afs2k5db. The MIT Kerberos people didn't want it, > and the OpenAFS people understandably didn't want to ship with something > that required private header files and functions and was almost certainly > going to break in future MIT Kerberos releases. So that's the situation > we're in now, to provide some history. > > Now, what SHOULD we do? Well, if it was up to me, I think afs2k5db > should be rewritten to use only public krb5 API functions and > manually do all of the encoding necessary to create dump file records > (most of that is there; you would need to parse the stash file and > encrypt the principal keys yourself, but that isn't terrible). > Since MIT Kerberos generally supports older dump file formats this > would be reasonably future-proof. If this was done, I think it > would be reasonable to ship this program with OpenAFS. But the > problem here is I don't see who is going to do the work; obviously > I transitioned our cell years ago, and I have no motivation or time > to do work on fixing up afs2k5db. I think most other people are > in a similar situation. While I regret that we're where we are > now, that's the situation as I see it. Unfortunately that isn't > much help to you. > > Regarding your specific compilation problem, Jeff ... looks like > to me that swapping the order of the includes of k5-int.h and krb5.h > would be a good first step. But like Jeff Altman already told you, > newer versions of Kerberos are unlikely to work with it. > > --Ken > From jaltman@secure-endpoints.com Thu Oct 25 18:02:54 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 13:02:54 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: References: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> Message-ID: <4720CC3E.1040209@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms090204010801050205000309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brandon S. Allbery KF8NH wrote: > > On Oct 25, 2007, at 12:36 , Ken Hornstein wrote: > >> would be reasonable to ship this program with OpenAFS. But the >> problem here is I don't see who is going to do the work; obviously >> I transitioned our cell years ago, and I have no motivation or time >> to do work on fixing up afs2k5db. I think most other people are >> in a similar situation. While I regret that we're where we are >> now, that's the situation as I see it. Unfortunately that isn't >> much help to you. > > *half-facetiously wonders if it'd be easier to convince Love to unbundle > hprop* You could certainly use the Heimdal tools to perform the database conversion Jeffrey Altman --------------ms090204010801050205000309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxNzAyNTRaMCMGCSqGSIb3DQEJBDEWBBS9iLUV //D/v1ol0jnJTTPWsdDAcDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAUzJxfLBmrgVAT77HbqZJVTceaWDTSbT6zqbOK+vPqzI++Y6qNt0U KRca7p6mNfbzBxzlr1IDikdWwSsnPiSVV5PrXael+usORzBc1X2OF5U7Fs+VVwdit7h648xF w64HL/XqmajFAAqIWVBqIAgsv6Yd5sKiS3bGLXEdcVVnx/RQrbZhaf8WQC7Cbf9YN315bSfY Jlj83FHjhlOJpXgfcqBnc/bwI5mwZwNPkA9r9T9CPdnZXFpBfZ4SAqqA37TQQm5KQf4lrPkO wqabLYgsvc90fo03Ow6iLg2NE+jIBqeFdQfEeTztIZ1isZQgZ5nENy1CgGZSou1JB2r2ppwh cAAAAAAAAA== --------------ms090204010801050205000309-- From scs@umich.edu Thu Oct 25 18:06:24 2007 From: scs@umich.edu (Steve Simmons) Date: Thu, 25 Oct 2007 13:06:24 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> <471F34AB.4030601@msu.edu> Message-ID: <3554D723-8DA7-4DB4-A888-8ACCF8144F48@umich.edu> --Apple-Mail-19-276419910 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've got a variety of scripts to do volume moves in interesting ways, here's a summary: grabuser: Run it on an afs server, it moves the users volume 'here'. mvvols: read a list of volumes, move every n-th one as prescribed. Useful for thinning a file server. On Oct 24, 2007, at 12:34 PM, Derrick Brashear wrote: > On 10/24/07, Steven Jenkins wrote: > > It has _everything_ to do with namespace management. In absence of > better tools, people are using vos release to do just that. Note that > vos release isn't a bad tool; it's just being stretched beyond its > design because people need a way to do versioning of their namespaces. > > you want to dump and restore volumes. that's ugly. it's not a > namespace issue; you want versioned volume clones. Versioned clones. Now *that's* an interesting idea. I predict great client-side confusion. Gotta be an afs3 thing. --Apple-Mail-19-276419910 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I've got a variety of scripts to do volume moves in interesting ways, = here's a summary:

grabuser: Run it on an afs = server, it moves the users volume 'here'.

mvvols: read a list of = volumes, move every n-th one as prescribed. Useful for thinning a file = server.

On Oct 24, 2007, at 12:34 PM, Derrick = Brashear wrote:
On 10/24/07, Steven = Jenkins <steven.jenkins@gmail.com> = wrote:

It has _everything_ to do with namespace = management.=A0=A0In absence of
better tools, people are using vos = release to do just that.=A0=A0Note that
vos release isn't a bad tool; = it's just being stretched beyond its
design because people need a way = to do versioning of their namespaces.

you want to = dump and restore volumes. that's ugly. it's not a namespace issue; you = want versioned volume = clones.

Versioned clones. Now = *that's* an interesting idea. I predict great client-side confusion. = Gotta be an afs3 thing.
= --Apple-Mail-19-276419910-- From kenh@cmf.nrl.navy.mil Thu Oct 25 18:07:50 2007 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Thu, 25 Oct 2007 13:07:50 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720CA16.2020401@secure-endpoints.com> Message-ID: <200710251707.l9PH7pSA006923@ginger.cmf.nrl.navy.mil> >The MIT License is compatible with OpenAFS. Someone could simply copy >the necessary routines out of MIT Kerberos and build a package that >doesn't require MIT Kerberos at all. The problem is that since crypto functions are involved, it would require a good chunk of the MIT library (and the db library). >Or the inverse could be done. The kaserver database routines could be >extracted and added to a tool that could be built by MIT without AFS >being present. Since MIT already has all of the crypto library >functions necessary, going in this direction might be less work. Actually, afs2k5db doesn't link against AFS at all. It uses AFS header files, but you could get around that. I agree with you that logically afs2k5db should probably live in MIT Kerberos ... but good luck in fighting THAT windmill :-/ The reason I suggested fixing afs2k5db up and putting it in OpenAFS was that it didn't require Hell to freeze over to make it happen :-) --Ken From jaltman@secure-endpoints.com Thu Oct 25 18:35:48 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 13:35:48 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <200710251707.l9PH7pSA006923@ginger.cmf.nrl.navy.mil> References: <200710251707.l9PH7pSA006923@ginger.cmf.nrl.navy.mil> Message-ID: <4720D3F4.8040904@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms040901020806060107000100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > I agree with you that logically afs2k5db should probably live in > MIT Kerberos ... but good luck in fighting THAT windmill :-/ The > reason I suggested fixing afs2k5db up and putting it in OpenAFS was > that it didn't require Hell to freeze over to make it happen :-) Trust me. I am well aware of it. Still if someone did the work and presented it to them, now that they are a Consortium it might be possible to make a business case to them instead of a technical one. This is one battle I am going to stay away from. --------------ms040901020806060107000100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxNzM1NDhaMCMGCSqGSIb3DQEJBDEWBBRCpvh7 F42j3a1eFP81hLPU9NLAtDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAW85tY3kyU7kUK8+kogySyE4R2eWCpJRXLXynZtzRU5oti8s3M3qb 0HGICAMtE8VTXRQnuCYpXEjH0jit1Kg88DtnrntxgEGquhCZQ3e4e7hHbXxtaKdgPkFQ5JQH FXb78+eIYJ/EDO/tzA7jLGvU01d/CcCZ0+fhMkNqtlYbp3XXUWrLqGeJf9k9L2BMOxm3OEoR a7noDNUL35YtAnp+F82QclZHVIty6BEAJ8L1sQUP17XrhfAJQ5sWVuCTvpIM2rijKHs8wMDZ /jPvlx4clBj9WaIcSR81CVMjEYOa8GJ75ab3jsedF9GyIaBwKkDOUQ53NuYMiuyvlNDk0OjV NQAAAAAAAA== --------------ms040901020806060107000100-- From jose.calhariz@tagus.ist.utl.pt Thu Oct 25 19:12:35 2007 From: jose.calhariz@tagus.ist.utl.pt (Jose Calhariz) Date: Thu, 25 Oct 2007 19:12:35 +0100 Subject: [OpenAFS] Strategy for disaster recover of an AFS fileserver Message-ID: <20071025181234.GA30406@copernico.tagus.ist.utl.pt> --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In recent past I had lost a /vicepa partition with half of the volumes of my cell and found that my backup procedure is not fast enough for recovering so many volumes and data. I am using amanda without afs patch. What plans do you have for quick recovering from massive loss of data on an AFS cell? Jos=E9 Calhariz --=20 P.S. [En_US] The sig below is from my random sig-generator, which strangely often seems to pick signatures which are apropriate to the message at hand! P.S. [Pt_Pt] A assinatura em baixo =E9 do gerador aleat=F3rio de assinaturas, que estranhamente, escolhe com frequ=EAncia assinaturas que parecem apropriadas ao email! -- N=E3o sou 100% in=FAtil: sempre posso servir de mau exemplo... --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHINySQlvqh9sPbBoRAlKXAJ42/nVjUO+TimPPAliZDPm0/sVCHwCfdpCZ vue9dVDGNp7sOfeyLsMuHxU= =TelK -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From l.schimmer@cgv.tugraz.at Thu Oct 25 20:09:11 2007 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Thu, 25 Oct 2007 21:09:11 +0200 Subject: [OpenAFS] Strategy for disaster recover of an AFS fileserver In-Reply-To: <20071025181234.GA30406@copernico.tagus.ist.utl.pt> References: <20071025181234.GA30406@copernico.tagus.ist.utl.pt> Message-ID: <4720E9D7.8070806@cgv.tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jose Calhariz wrote: > In recent past I had lost a /vicepa partition with half of the volumes > of my cell and found that my backup procedure is not fast enough for > recovering so many volumes and data. I am using amanda without afs > patch. >=20 > What plans do you have for quick recovering from massive loss of data > on an AFS cell? first: no loss of data ;-) second: a extra server with HD space and a RO copy of ALL volumes third: 2-4 RO copies of all RW volumes spread over 4 fileservers fourth: vos convertRotoRW :-) > Jos=E9 Calhariz >=20 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIOnXmWhuE0qbFyMRAkQ8AJ9jgF+LbJ9HB8dQeQocZ1d/eMQxOwCfTZER ephhGP83jzFJnPUw5umDxMY=3D =3DdWui -----END PGP SIGNATURE----- From cclausen@acm.org Thu Oct 25 20:19:20 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Thu, 25 Oct 2007 14:19:20 -0500 Subject: [OpenAFS] Strategy for disaster recover of an AFS fileserver References: <20071025181234.GA30406@copernico.tagus.ist.utl.pt> <4720E9D7.8070806@cgv.tugraz.at> Message-ID: <06C4E2F695AF4B989A3105BAB81EE63C@CDCHOME> Lars Schimmer wrote: > Jose Calhariz wrote: >> In recent past I had lost a /vicepa partition with half of the >> volumes of my cell and found that my backup procedure is not fast >> enough for recovering so many volumes and data. I am using amanda >> without afs patch. >> >> What plans do you have for quick recovering from massive loss of data >> on an AFS cell? > > first: no loss of data ;-) > second: a extra server with HD space and a RO copy of ALL volumes > third: 2-4 RO copies of all RW volumes spread over 4 fileservers > fourth: vos convertRotoRW I specific fs mkm -rw when doing this, otherwise users end up reading the RO version, which is not usually want they want. Also, you need to use the namei fileserver. Vos convertROtoRW does not work with the inode fileserver. < References: <471F8A21.1020802@columbia.edu> <471FA3C4.70402@prodesigncad.de> <20071025.090215.98471013.haba@habarber.pdc.kth.se> Message-ID: On Thu, 25 Oct 2007, Harald Barth wrote: > If different database server versions would generate pain, I would > had to do something about the following a long time ago... > > $ /usr/openafs/sbin/rxdebug anna 7003 -v > Trying 130.237.232.112 (port 7003): > AFS version: OpenAFS 1.4.0 built 2005-11-15 > > $ /usr/openafs/sbin/rxdebug hokkigai 7003 -v > Trying 130.237.232.114 (port 7003): > AFS version: OpenAFS 1.2.11 built 2004-01-12 > > $ /usr/openafs/sbin/rxdebug crab 7003 -v > Trying 130.237.232.29 (port 7003): > AFS version: OpenAFS 1.4.2 built 2006-11-09 Very interesting. > I vaguely remember a "take everything down" scenario necessary many > many years ago. Yeah, I remember that, too. I think it was something like IBM AFS 3.4 --> 3.5. It was because of a database format change, IIRC. So this suggests we don't need to worry too much about our database servers, just do them whenever is convenient. Which leads into a different question: Is there any reason not to start off by upgrading one or more of our fileservers from 1.2.13 to 1.4.4, while leaving the database servers at 1.2.13 until sometime later? For completeness I should state that the prime motivation here is to get to a point where our Windows users can begin taking advantage of file locking. (Obviously their client binaries need to be up to date, too.) -Mitch From jaltman@secure-endpoints.com Thu Oct 25 22:35:48 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 17:35:48 -0400 Subject: [OpenAFS] Server upgrade time; which is the right way? In-Reply-To: References: <471F8A21.1020802@columbia.edu> <471FA3C4.70402@prodesigncad.de> <20071025.090215.98471013.haba@habarber.pdc.kth.se> Message-ID: <47210C34.1040305@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms000108040500040808010802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mitch Collinsworth wrote: > Which leads into a different question: Is there any reason not to start > off by upgrading one or more of our fileservers from 1.2.13 to 1.4.4, while > leaving the database servers at 1.2.13 until sometime later? There is no specific requirement that one be done before the other. We haven't changed the data formats or protocol exchanges up to this point. > For completeness I should state that the prime motivation here is to get to > a point where our Windows users can begin taking advantage of file locking. > (Obviously their client binaries need to be up to date, too.) File locking is simulated in the client. The client obtains a full file lock from the file server and then doles out byte range locks locally to the application. The change in the file server from 1.2.13 to 1.4.5 will provide you with large file support and a modification to the locking semantics so that users that have 'w' permission do not need to explicitly have 'k' permission. Of course, if you have already granted 'k' permission to your users there will be nothing gained. Is there something else you were thinking of? --------------ms000108040500040808010802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUyMTM1NDhaMCMGCSqGSIb3DQEJBDEWBBS59xtx +bGVoiineCoCiKVZ0L1mRjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEALzwMabrpwrO4kXVAzckEIKB9o2GnyUyK8U9Q+VIzPn8EahB0rI/G vvOv4UWnlMfZYG5Hus34ZbT1Bdm97zgdwkI7dQlfQ66tkRSSyM2oBbRwNrP0rTcwymCjwIGI t405WFsHWbzezRlV7ONJCVdODUOzRp80aYjJ82pkWG3u6nVgdwpF//+9GXrghrf3z+NmJxwj 2tX6oDTySI5En5lY8BwasDpvAJ7Pk8TJT28Mxu3zv1Ij7nRPG9fF8qxd1Rchy1cbCXb7l6mV Wv6yQA6HD3P7zJAsjGJ2kZ5BXGJD1FS/OKcyrk3aa6rgdGick/eEL5bI8M3oUgd4p1qBFLo7 BQAAAAAAAA== --------------ms000108040500040808010802-- From mitch@ccmr.cornell.edu Thu Oct 25 22:59:08 2007 From: mitch@ccmr.cornell.edu (Mitch Collinsworth) Date: Thu, 25 Oct 2007 17:59:08 -0400 (EDT) Subject: [OpenAFS] Server upgrade time; which is the right way? In-Reply-To: <47210C34.1040305@secure-endpoints.com> References: <471F8A21.1020802@columbia.edu> <471FA3C4.70402@prodesigncad.de> <20071025.090215.98471013.haba@habarber.pdc.kth.se> <47210C34.1040305@secure-endpoints.com> Message-ID: On Thu, 25 Oct 2007, Jeffrey Altman wrote: > File locking is simulated in the client. The client obtains a full file > lock from the file server and then doles out byte range locks locally to > the application. > > The change in the file server from 1.2.13 to 1.4.5 will provide you with > large file support and a modification to the locking semantics so that > users that have 'w' permission do not need to explicitly have 'k' > permission. Of course, if you have already granted 'k' permission to > your users there will be nothing gained. No kidding... I knew about the simulated byte-range locks using full file locks bit, but I don't remember knowing that giving users 'k' will accomplish the same thing. Do we really need to be at 1.4.5 to get the new locking semantics? I thought the locking support change happened earlier. > Is there something else you were thinking of? Apparently not. I was thinking that we needed to upgrade the fileservers in order to begin taking advantage of the simulated file locking feature for Windows. Thank you for the clarification. -Mitch From jblaine@kickflop.net Thu Oct 25 23:08:57 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Thu, 25 Oct 2007 18:08:57 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <4720C93E.2060304@kickflop.net> References: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> <4720C93E.2060304@kickflop.net> Message-ID: <472113F9.4060704@kickflop.net> FWIW re: building afs2k5db with old Kerberos dist... MIT Kerberos 1.2 : Has no krb5-config = no good MIT Kerberos 1.3 : Fails to build: /blah/krb5-1.3/src/include/k5-int.h:1783: error: parse error before "krb5_donot_replay" MIT Kebreros 1.4.4 : Fails (without mods) to build: #error krb5.h included before k5-int.h Moved "#include " before the include for krb5.h in afs2k5db.c Had to do the same thing in k5dbsubs.c Built From jaltman@secure-endpoints.com Thu Oct 25 23:44:06 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Oct 2007 18:44:06 -0400 Subject: [OpenAFS] Server upgrade time; which is the right way? In-Reply-To: References: <471F8A21.1020802@columbia.edu> <471FA3C4.70402@prodesigncad.de> <20071025.090215.98471013.haba@habarber.pdc.kth.se> <47210C34.1040305@secure-endpoints.com> Message-ID: <47211C36.5020903@secure-endpoints.com> Mitch Collinsworth wrote: > > On Thu, 25 Oct 2007, Jeffrey Altman wrote: > >> File locking is simulated in the client. The client obtains a full file >> lock from the file server and then doles out byte range locks locally to >> the application. >> >> The change in the file server from 1.2.13 to 1.4.5 will provide you with >> large file support and a modification to the locking semantics so that >> users that have 'w' permission do not need to explicitly have 'k' >> permission. Of course, if you have already granted 'k' permission to >> your users there will be nothing gained. > > No kidding... I knew about the simulated byte-range locks using full file > locks bit, but I don't remember knowing that giving users 'k' will > accomplish the same thing. Do we really need to be at 1.4.5 to get the > new locking semantics? I thought the locking support change happened > earlier. The locking semantic change occurred in 1.4.2. However, you will want to use 1.4.5 when it is out tomorrow. Jeffrey Altman From tkeiser@gmail.com Thu Oct 25 23:52:08 2007 From: tkeiser@gmail.com (Tom Keiser) Date: Thu, 25 Oct 2007 18:52:08 -0400 Subject: [OpenAFS] Automatic move of volumes In-Reply-To: References: <1193225691.11351.34.camel@thor> Message-ID: <217964d60710251552y3a56fdbh8ecfa3ce66329f2a@mail.gmail.com> On 10/24/07, Steven Jenkins wrote: > On 10/24/07, Derrick Brashear wrote: > > > > > > It has _everything_ to do with namespace management. In absence of > > > better tools, people are using vos release to do just that. Note that > > > vos release isn't a bad tool; it's just being stretched beyond its > > > design because people need a way to do versioning of their namespaces. > > > > you want to dump and restore volumes. that's ugly. it's not a namespace > > issue; you want versioned volume clones. > > > > dump/restore is just a mechanism in lieu of a volume copy operation. > Versionized clones could be interesting in this context, but I would > prefer to stay away from that approach as it makes it harder to > recover & see changes in the base volume. I think having one RW per > 'generation' of ROs is reasonable. > I agree that having one RW per generation is very useful. Ideally, I'd like to see a volume group become a more flexible container which contains an arbitary inheritance tree structure. For instance, it would be useful to allow creation of addtional forked RW volumes within a volume group. This would, in effect, give us the equivalent of a CVS branch tag for a volume. Obviously, the existing model where a volume name is a tightly coupled 1:1 mapping onto the volume group is a limitation which would need to be lifted. But, there are other reasons why making the name map more flexible would be beneficial (e.g. providing useful names for infinite backup clones, etc.) > With versionized clones, you would need to create a mechanism to have > potentially infinite numbers of clones, with arbitrary generation > identifiers (eg, some would be ok with '1', '2', ..., but some would > want 'alpha', 'beta', ..., or 'dev', 'prod', etc). IMO, that's better > done outside of the volume itself. > Not sure I agree. Providing this type of metadata in the volume management system itself has value (provided it's done in a typeful, standardized manner). For instance, if we ever integrate an automated volume migration/balancing system, we will want to access this type of information to prioritize where certain volumes are stored. -Tom From fbo2@gmx.net Fri Oct 26 08:19:29 2007 From: fbo2@gmx.net (Frank Burkhardt) Date: Fri, 26 Oct 2007 09:19:29 +0200 Subject: [OpenAFS] Strategy for disaster recover of an AFS fileserver In-Reply-To: <4720E9D7.8070806@cgv.tugraz.at> References: <20071025181234.GA30406@copernico.tagus.ist.utl.pt> <4720E9D7.8070806@cgv.tugraz.at> Message-ID: <20071026071929.GB25684@defiant.alpha> Hi, On Thu, Oct 25, 2007 at 09:09:11PM +0200, Lars Schimmer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jose Calhariz wrote: > > In recent past I had lost a /vicepa partition with half of the volumes > > of my cell and found that my backup procedure is not fast enough for > > recovering so many volumes and data. I am using amanda without afs > > patch. > > > > What plans do you have for quick recovering from massive loss of data > > on an AFS cell? > > first: no loss of data ;-) > second: a extra server with HD space and a RO copy of ALL volumes > third: 2-4 RO copies of all RW volumes spread over 4 fileservers > fourth: vos convertRotoRW You forgot three-dot-fifth: Put RO- and RW-servers as far as possible away from each other. This is worth more than a fire insurance. Regards, Frank From rader@ginseng.hep.wisc.edu Fri Oct 26 13:11:14 2007 From: rader@ginseng.hep.wisc.edu (rader@ginseng.hep.wisc.edu) Date: Fri, 26 Oct 2007 07:11:14 -0500 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <472113F9.4060704@kickflop.net> References: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> <4720C93E.2060304@kickflop.net> <472113F9.4060704@kickflop.net> Message-ID: <200710261211.l9QCBE25017312@ginseng.hep.wisc.edu> Did you try this?? - build krb5 1.3.x - apply the enclosed patch - build afs-krb5 2.0 via ./configure --with-krb5-src=/path/to/your/krb5-1.3.x/src make steve -- > ---- Original Message ---- > From: Jeff Blaine > FWIW re: building afs2k5db with old Kerberos dist... > > MIT Kerberos 1.2 : Has no krb5-config = no good > > MIT Kerberos 1.3 : Fails to build: > > /blah/krb5-1.3/src/include/k5-int.h:1783: > error: parse error before "krb5_donot_replay" > > MIT Kebreros 1.4.4 : Fails (without mods) to build: > > #error krb5.h included before k5-int.h > > Moved "#include " before the > include for krb5.h in afs2k5db.c > > Had to do the same thing in k5dbsubs.c > > Built --- k5-int.h.orig 2004-01-05 16:49:32.000000000 -0600 +++ k5-int.h 2007-09-14 20:36:11.000000000 -0500 @@ -1801,6 +1801,7 @@ krb5_pointer data; }; +#if 0 struct _krb5_rc_ops { krb5_magic magic; char *type; @@ -1823,6 +1824,7 @@ krb5_error_code (KRB5_CALLCONV *resolve) (krb5_context, krb5_rcache, char *); }; +#endif typedef struct _krb5_rc_ops krb5_rc_ops; From hamish@travellingkiwi.com Fri Oct 26 17:10:18 2007 From: hamish@travellingkiwi.com (Hamish) Date: Fri, 26 Oct 2007 17:10:18 +0100 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number Message-ID: <200710261710.18721.hamish@travellingkiwi.com> I've got openAFS 1.4.4 (RPM x86_64 downloaded from openafs.org) running on RHES4 with kerberosV. Kerberos is installed & seems to be working OK. I can get a krb ticket with krb5 no problems. kadmin etc all work. I can create new principals (e.g. afs). aklog works. It get a token and then tokens shows the token successfully generated... Working so far. However when I try to execute a command that requires a token (e..g box restart, vos create etc), I get bos: failed to restart instance fs (ticket contained unknown key version number) I'm assumign thats ince aklog is in the RPM's that we're all OK for working with krb5. The fact that aklog works seems to confirm that. Why the heck do I get an unknown key version when trying to do anything? I've googled till I'm blue in the face and have only found some really really old emails asking questions with no answers... The Wiki seems devoid of any info unless it's using kaserver when it comes to krb at all... Anyone? TIA Hamish. From shadow@gmail.com Fri Oct 26 17:17:57 2007 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 26 Oct 2007 12:17:57 -0400 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number In-Reply-To: <200710261710.18721.hamish@travellingkiwi.com> References: <200710261710.18721.hamish@travellingkiwi.com> Message-ID: ------=_Part_6274_13411893.1193415477935 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline all aklog working tells you is that there's a key for afs/(cell) in your krb5 database. doesn't tell you a thing about whether it matches what your servers know about. On 10/26/07, Hamish wrote: > > > I've got openAFS 1.4.4 (RPM x86_64 downloaded from openafs.org) running on > RHES4 with kerberosV. Kerberos is installed & seems to be working OK. I > can > get a krb ticket with krb5 no problems. kadmin etc all work. I can create > new > principals (e.g. afs). > > aklog works. It get a token and then tokens shows the token successfully > generated... Working so far. > > However when I try to execute a command that requires a token (e..g box > restart, vos create etc), I get > > bos: failed to restart instance fs (ticket contained unknown key version > number) > > I'm assumign thats ince aklog is in the RPM's that we're all OK for > working > with krb5. The fact that aklog works seems to confirm that. > > Why the heck do I get an unknown key version when trying to do anything? > I've > googled till I'm blue in the face and have only found some really really > old > emails asking questions with no answers... The Wiki seems devoid of any > info > unless it's using kaserver when it comes to krb at all... > > > Anyone? > > TIA > Hamish. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > ------=_Part_6274_13411893.1193415477935 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline all aklog working tells you is that there's a key for afs/(cell) in your krb5 database.

doesn't tell you a thing about whether it matches what your servers know about.


On 10/26/07, Hamish <hamish@travellingkiwi.com> wrote:

I've got openAFS 1.4.4 (RPM x86_64 downloaded from openafs.org) running on
RHES4 with kerberosV. Kerberos is installed & seems to be working OK. I can
get a krb ticket with krb5 no problems. kadmin etc all work. I can create new
principals (e.g. afs).

aklog works. It get a token and then tokens shows the token successfully
generated... Working so far.

However when I try to execute a command that requires a token (e..g box
restart, vos create etc), I get

bos: failed to restart instance fs (ticket contained unknown key version
number)

I'm assumign thats ince aklog is in the RPM's that we're all OK for working
with krb5. The fact that aklog works seems to confirm that.

Why the heck do I get an unknown key version when trying to do anything? I've
googled till I'm blue in the face and have only found some really really old
emails asking questions with no answers... The Wiki seems devoid of any info
unless it's using kaserver when it comes to krb at all...


Anyone?

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

------=_Part_6274_13411893.1193415477935-- From cclausen@acm.org Fri Oct 26 17:17:50 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Fri, 26 Oct 2007 11:17:50 -0500 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number References: <200710261710.18721.hamish@travellingkiwi.com> Message-ID: Hamish wrote: > Why the heck do I get an unknown key version when trying to do > anything? I've googled till I'm blue in the face and have only found > some really really old emails asking questions with no answers... The > Wiki seems devoid of any info unless it's using kaserver when it > comes to krb at all... I suspect that your KeyFile contains an entry where the kvno on the KDC does not match. Delete your KeyFile, recreate a keytab and re-run asetkey (using the proper kvno) to generate a good KeyFile. Copy this KeyFile to all of your AFS servers and restart all of them. < References: <200710261710.18721.hamish@travellingkiwi.com> Message-ID: <200710261749.35377.hamish@travellingkiwi.com> On Friday 26 October 2007 17:17, Christopher D. Clausen wrote: > Hamish wrote: > > Why the heck do I get an unknown key version when trying to do > > anything? I've googled till I'm blue in the face and have only found > > some really really old emails asking questions with no answers... The > > Wiki seems devoid of any info unless it's using kaserver when it > > comes to krb at all... > > I suspect that your KeyFile contains an entry where the kvno on the KDC > does not match. Delete your KeyFile, recreate a keytab and re-run > asetkey (using the proper kvno) to generate a good KeyFile. Copy this > KeyFile to all of your AFS servers and restart all of them. > Thanks. I'd just taken that route when I got your reply. (I think I probably stuffed it up trying to build the second machine & rerunning some of the commands that should only have been run once. Joys of trying to adapt a readme I found on the internet that only deals withinstalling a single machine :). The local machine works fine now. But when I try to run a command remotely (e.g. run bos restart from the first server against the second server I installed) it fails with '(you are not authorised for this operation)' Both work locally though... And if I append -localauth to the command on machine1 to restart machine2 it works... Hamish. From hamish@travellingkiwi.com Fri Oct 26 17:54:07 2007 From: hamish@travellingkiwi.com (Hamish) Date: Fri, 26 Oct 2007 17:54:07 +0100 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number In-Reply-To: <200710261749.35377.hamish@travellingkiwi.com> References: <200710261710.18721.hamish@travellingkiwi.com> <200710261749.35377.hamish@travellingkiwi.com> Message-ID: <200710261754.07552.hamish@travellingkiwi.com> On Friday 26 October 2007 17:49, Hamish wrote: > On Friday 26 October 2007 17:17, Christopher D. Clausen wrote: > > Hamish wrote: > > > Why the heck do I get an unknown key version when trying to do > > > anything? I've googled till I'm blue in the face and have only found > > > some really really old emails asking questions with no answers... The > > > Wiki seems devoid of any info unless it's using kaserver when it > > > comes to krb at all... > > > > I suspect that your KeyFile contains an entry where the kvno on the KDC > > does not match. Delete your KeyFile, recreate a keytab and re-run > > asetkey (using the proper kvno) to generate a good KeyFile. Copy this > > KeyFile to all of your AFS servers and restart all of them. > > Thanks. I'd just taken that route when I got your reply. (I think I > probably stuffed it up trying to build the second machine & rerunning some > of the commands that should only have been run once. Joys of trying to > adapt a readme I found on the internet that only deals withinstalling a > single machine :). > The local machine works fine now. But when I try to run a command remotely > (e.g. run bos restart from the first server against the second server I > installed) it fails with > > '(you are not authorised for this operation)' > > Both work locally though... And if I append -localauth to the command on > machine1 to restart machine2 it works... > Whoops... Telling lies... My token was old... I unlog'ed, kdestroyed and tried again (On machine 2)... kinit works no problems, but aklog is hanging after 'About to revolve name admin to is in cell xxx.xx.x.com' H From cclausen@acm.org Fri Oct 26 18:09:26 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Fri, 26 Oct 2007 12:09:26 -0500 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number References: <200710261710.18721.hamish@travellingkiwi.com> <200710261749.35377.hamish@travellingkiwi.com> <200710261754.07552.hamish@travellingkiwi.com> Message-ID: <21ED963C20D44AA09EF56B7BBA026254@CDCHOME> Hamish wrote: > On Friday 26 October 2007 17:49, Hamish wrote: >> Thanks. I'd just taken that route when I got your reply. (I think I >> probably stuffed it up trying to build the second machine & >> rerunning some of the commands that should only have been run once. >> Joys of trying to adapt a readme I found on the internet that only >> deals withinstalling a single machine :). >> The local machine works fine now. But when I try to run a command >> remotely (e.g. run bos restart from the first server against the >> second server I installed) it fails with >> >> '(you are not authorised for this operation)' >> >> Both work locally though... And if I append -localauth to the >> command on machine1 to restart machine2 it works... >> > > Whoops... Telling lies... My token was old... I unlog'ed, kdestroyed > and tried again (On machine 2)... kinit works no problems, but aklog > is hanging after > > 'About to revolve name admin to is in cell xxx.xx.x.com' Check your AFS server log files for any errors. I suspect something isn't running correctly. Or, you did not add a PTS account for the user you are trying to obtain tokens for. If you'd like more interactive help, please join the #openafs channel on the Freenode IRC network. < References: <200710261710.18721.hamish@travellingkiwi.com> <200710261754.07552.hamish@travellingkiwi.com> <21ED963C20D44AA09EF56B7BBA026254@CDCHOME> Message-ID: <200710261827.51091.hamish@travellingkiwi.com> On Friday 26 October 2007 18:09, Christopher D. Clausen wrote: > Hamish wrote: > > On Friday 26 October 2007 17:49, Hamish wrote: > >> Thanks. I'd just taken that route when I got your reply. (I think I > >> probably stuffed it up trying to build the second machine & > >> rerunning some of the commands that should only have been run once. > >> Joys of trying to adapt a readme I found on the internet that only > >> deals withinstalling a single machine :). > >> The local machine works fine now. But when I try to run a command > >> remotely (e.g. run bos restart from the first server against the > >> second server I installed) it fails with > >> > >> '(you are not authorised for this operation)' > >> > >> Both work locally though... And if I append -localauth to the > >> command on machine1 to restart machine2 it works... > > > > Whoops... Telling lies... My token was old... I unlog'ed, kdestroyed > > and tried again (On machine 2)... kinit works no problems, but aklog > > is hanging after > > > > 'About to revolve name admin to is in cell xxx.xx.x.com' > > Check your AFS server log files for any errors. I suspect something > isn't running correctly. Or, you did not add a PTS account for the user > you are trying to obtain tokens for. > Spelling mistake in my CellServDB file... Damnit I hate that... I also just discovered that aklog won't work unless I've started the AFS client... Didn't realise that was mandatory... The user was admin... e.g. kinit admin aklog Now it works (getting the tokens), but I'm still not authorised for doing restarts of the second server, vos create etc... Nothing logged as to why. > If you'd like more interactive help, please join the #openafs channel on > the Freenode IRC network. > Hmm... Wonder if I can get there from here (At a client site, firewall might kill me. I may have to work on it over the weekend from home where I can get to things like IRC). Cheers for all your help... pretty damn interactive even over email :) Hamish. From cclausen@acm.org Fri Oct 26 18:38:24 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Fri, 26 Oct 2007 12:38:24 -0500 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number References: <200710261710.18721.hamish@travellingkiwi.com> <200710261754.07552.hamish@travellingkiwi.com> <21ED963C20D44AA09EF56B7BBA026254@CDCHOME> <200710261827.51091.hamish@travellingkiwi.com> Message-ID: Hamish wrote: > On Friday 26 October 2007 18:09, Christopher D. Clausen wrote: >> Hamish wrote: >>> On Friday 26 October 2007 17:49, Hamish wrote: >>>> Thanks. I'd just taken that route when I got your reply. (I think I >>>> probably stuffed it up trying to build the second machine & >>>> rerunning some of the commands that should only have been run once. >>>> Joys of trying to adapt a readme I found on the internet that only >>>> deals withinstalling a single machine :). >>>> The local machine works fine now. But when I try to run a command >>>> remotely (e.g. run bos restart from the first server against the >>>> second server I installed) it fails with >>>> >>>> '(you are not authorised for this operation)' >>>> >>>> Both work locally though... And if I append -localauth to the >>>> command on machine1 to restart machine2 it works... >>> >>> Whoops... Telling lies... My token was old... I unlog'ed, kdestroyed >>> and tried again (On machine 2)... kinit works no problems, but aklog >>> is hanging after >>> >>> 'About to revolve name admin to is in cell xxx.xx.x.com' >> >> Check your AFS server log files for any errors. I suspect something >> isn't running correctly. Or, you did not add a PTS account for the >> user you are trying to obtain tokens for. > > Spelling mistake in my CellServDB file... Damnit I hate that... I > also just discovered that aklog won't work unless I've started the > AFS client... Didn't realise that was mandatory... The user was > admin... e.g. Oh, yeah, need to have AFS client running in order for the store tokens ioctl to work. > Now it works (getting the tokens), but I'm still not authorised for > doing restarts of the second server, vos create etc... Nothing logged > as to why. Are you in that server's UserList? bos listusers to check. >> If you'd like more interactive help, please join the #openafs >> channel on the Freenode IRC network. > > Hmm... Wonder if I can get there from here (At a client site, A client? As in someone is paying you to ask me AFS questions on a mailing list? > firewall might kill me. I may have to work on it over the weekend > from home where I can get to things like IRC). < References: <200710261710.18721.hamish@travellingkiwi.com> <21ED963C20D44AA09EF56B7BBA026254@CDCHOME> <200710261827.51091.hamish@travellingkiwi.com> Message-ID: <200710261843.13940.hamish@travellingkiwi.com> On Friday 26 October 2007 18:27, Hamish wrote: > On Friday 26 October 2007 18:09, Christopher D. Clausen wrote: > > Hamish wrote: > > > On Friday 26 October 2007 17:49, Hamish wrote: > > >> Thanks. I'd just taken that route when I got your reply. (I think I > > >> probably stuffed it up trying to build the second machine & > > >> rerunning some of the commands that should only have been run once. > > >> Joys of trying to adapt a readme I found on the internet that only > > >> deals withinstalling a single machine :). > > >> The local machine works fine now. But when I try to run a command > > >> remotely (e.g. run bos restart from the first server against the > > >> second server I installed) it fails with > > >> > > >> '(you are not authorised for this operation)' > > >> [deleted] > > If you'd like more interactive help, please join the #openafs channel on > > the Freenode IRC network. > > Hmm... Wonder if I can get there from here (At a client site, firewall > might kill me. I may have to work on it over the weekend from home where I > can get to things like IRC). > yeah, can't get on at the moment... QUick question... When I kinit as admin & give my passwd, I get in klist the default principal 'admin', but the two service principals are krbtgt/... and afs/cellname@REALM. When I aklog & display the tokens, the tokens are AFS ID 1 tokens for afs@cell. is that right? Or should I get tokens for admin? (Sorry... I've been running AFS on kaserver for a few years with openafs & transarc (very old), and only now trying to run up a new cell on krb5... And it's not going well :) H From hamish@travellingkiwi.com Fri Oct 26 18:48:38 2007 From: hamish@travellingkiwi.com (Hamish) Date: Fri, 26 Oct 2007 18:48:38 +0100 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number In-Reply-To: References: <200710261710.18721.hamish@travellingkiwi.com> <200710261827.51091.hamish@travellingkiwi.com> Message-ID: <200710261848.38745.hamish@travellingkiwi.com> On Friday 26 October 2007 18:38, Christopher D. Clausen wrote: > Hamish wrote: > > On Friday 26 October 2007 18:09, Christopher D. Clausen wrote: > >> Hamish wrote: > >>> On Friday 26 October 2007 17:49, Hamish wrote: > >>>> Thanks. I'd just taken that route when I got your reply. (I think I > >>>> probably stuffed it up trying to build the second machine & > >>>> rerunning some of the commands that should only have been run once. > >>>> Joys of trying to adapt a readme I found on the internet that only > >>>> deals withinstalling a single machine :). > >>>> The local machine works fine now. But when I try to run a command > >>>> remotely (e.g. run bos restart from the first server against the > >>>> second server I installed) it fails with > >>>> > >>>> '(you are not authorised for this operation)' > >>>> > >>>> Both work locally though... And if I append -localauth to the > >>>> command on machine1 to restart machine2 it works... > >>> > >>> Whoops... Telling lies... My token was old... I unlog'ed, kdestroyed > >>> and tried again (On machine 2)... kinit works no problems, but aklog > >>> is hanging after > >>> > >>> 'About to revolve name admin to is in cell xxx.xx.x.com' > >> > >> Check your AFS server log files for any errors. I suspect something > >> isn't running correctly. Or, you did not add a PTS account for the > >> user you are trying to obtain tokens for. > > > > Spelling mistake in my CellServDB file... Damnit I hate that... I > > also just discovered that aklog won't work unless I've started the > > AFS client... Didn't realise that was mandatory... The user was > > admin... e.g. > > Oh, yeah, need to have AFS client running in order for the store tokens > ioctl to work. > > > Now it works (getting the tokens), but I'm still not authorised for > > doing restarts of the second server, vos create etc... Nothing logged > > as to why. > > Are you in that server's UserList? > > bos listusers to check. > > >> If you'd like more interactive help, please join the #openafs > >> channel on the Freenode IRC network. > > > > Hmm... Wonder if I can get there from here (At a client site, > > A client? As in someone is paying you to ask me AFS questions on a > mailing list? > No... As in I'm trying to get my afs working while waiting for a bus home... Public transport isn't what it used to be... H From dlg@dsrw.org Fri Oct 26 18:49:44 2007 From: dlg@dsrw.org (david l goodrich) Date: Fri, 26 Oct 2007 12:49:44 -0500 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number In-Reply-To: References: Message-ID: On Fri, 26 Oct 2007 12:38:24 -0500, "Christopher D. Clausen" wrote: > Hamish wrote: >> On Friday 26 October 2007 18:09, Christopher D. Clausen wrote: >>> If you'd like more interactive help, please join the #openafs >>> channel on the Freenode IRC network. >> >> Hmm... Wonder if I can get there from here (At a client site, >=20 > A client? As in someone is paying you to ask me AFS questions on a > mailing list? Wow. I'd ask for a cut of his fees if that's the case. --david From hamish@travellingkiwi.com Fri Oct 26 18:53:19 2007 From: hamish@travellingkiwi.com (Hamish) Date: Fri, 26 Oct 2007 18:53:19 +0100 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number In-Reply-To: References: <200710261710.18721.hamish@travellingkiwi.com> <200710261827.51091.hamish@travellingkiwi.com> Message-ID: <200710261853.19927.hamish@travellingkiwi.com> On Friday 26 October 2007 18:38, Christopher D. Clausen wrote: > Hamish wrote: > > On Friday 26 October 2007 18:09, Christopher D. Clausen wrote: > >> Hamish wrote: > >>> On Friday 26 October 2007 17:49, Hamish wrote: > >>>> Thanks. I'd just taken that route when I got your reply. (I think I > >>>> probably stuffed it up trying to build the second machine & > >>>> rerunning some of the commands that should only have been run once. > >>>> Joys of trying to adapt a readme I found on the internet that only > >>>> deals withinstalling a single machine :). > >>>> The local machine works fine now. But when I try to run a command > >>>> remotely (e.g. run bos restart from the first server against the > >>>> second server I installed) it fails with > >>>> > >>>> '(you are not authorised for this operation)' > >>>> > >>>> Both work locally though... And if I append -localauth to the > >>>> command on machine1 to restart machine2 it works... > >>> > >>> Whoops... Telling lies... My token was old... I unlog'ed, kdestroyed > >>> and tried again (On machine 2)... kinit works no problems, but aklog > >>> is hanging after > >>> > >>> 'About to revolve name admin to is in cell xxx.xx.x.com' > >> > >> Check your AFS server log files for any errors. I suspect something > >> isn't running correctly. Or, you did not add a PTS account for the > >> user you are trying to obtain tokens for. > > > > Spelling mistake in my CellServDB file... Damnit I hate that... I > > also just discovered that aklog won't work unless I've started the > > AFS client... Didn't realise that was mandatory... The user was > > admin... e.g. > > Oh, yeah, need to have AFS client running in order for the store tokens > ioctl to work. > > > Now it works (getting the tokens), but I'm still not authorised for > > doing restarts of the second server, vos create etc... Nothing logged > > as to why. > > Are you in that server's UserList? > > bos listusers to check. > Damn... Thanks... I used to install new servers by copying all those files... I was trying to cut corners and doit all by hand & missed the adduser command... Guess I need some more sleep... It is friday night... (My only excuse). Thanks for all your help. hamish From cclausen@acm.org Fri Oct 26 19:00:55 2007 From: cclausen@acm.org (Christopher D. Clausen) Date: Fri, 26 Oct 2007 13:00:55 -0500 Subject: [OpenAFS] openAFS 1.4.4 - ticket contained unknown key version number References: <200710261710.18721.hamish@travellingkiwi.com> <21ED963C20D44AA09EF56B7BBA026254@CDCHOME> <200710261827.51091.hamish@travellingkiwi.com> <200710261843.13940.hamish@travellingkiwi.com> Message-ID: Hamish wrote: > yeah, can't get on at the moment... > > QUick question... When I kinit as admin & give my passwd, I get in > klist the default principal 'admin', but the two service principals > are krbtgt/... and afs/cellname@REALM. Those are Kerberos TICKETS. > When I aklog & display the tokens, the tokens are AFS ID 1 tokens for > afs@cell. That is an AFS TOKEN. > is that right? Or should I get tokens for admin? (Sorry... I've been > running AFS on kaserver for a few years with openafs & transarc (very > old), and only now trying to run up a new cell on krb5... And it's > not going well :) The tokens are for admin. I bet if you run pts mem 1 you'll get back "admin" as the user. The afs@cell part just informs you that you have tokens in "cell" and the AFS ID tells you which user these tokens are for. < References: Message-ID: <20071026234628.GA17913@citi.umich.edu> The "Download Latest Release" link at the web site still goes to 1.4.5 pre5. From jaltman@secure-endpoints.com Sat Oct 27 01:30:59 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 26 Oct 2007 20:30:59 -0400 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release available In-Reply-To: <20071026234628.GA17913@citi.umich.edu> References: <20071026234628.GA17913@citi.umich.edu> Message-ID: <472286C3.3030004@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms040205010807090402010709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jim Rees wrote: > The "Download Latest Release" link at the web site still goes to 1.4.5 pre5. Works for me!!! --------------ms040205010807090402010709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjcwMDMwNTlaMCMGCSqGSIb3DQEJBDEWBBT1sJRT YykPe4sKCBtFUd4Wh1uY4TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAC4IBV43tD4mPu56mZAbmLcEH455bvxUH612sjs+tre/8F/ilz6Kv w3sf5jiu39xRFOc9KxkA2+XfBGK081gOuATCOkyaY3Z4tpaEzwt9GDplw1IvAZmyKHMu5VMK Z9VmrEnNSviftpkSCCRujpkz/G8BR0ROmyqyXhba1iQPqB9d6tWTc0T8Vo1oyqlbeGWInJIE DpHFnRj9FgOst/aUAO47v4KpI/+eDMmuOQyabJMIP4cFjqHH1ZQz6Y6schiWanCXNs79q2vx ZqcVliWthM/pOTKXnBNFHGup8S5MBErkB8/+VtJa3cnCzmlfUP0g9AhU9v+KUZ2VMdZ2Pt0n 4QAAAAAAAA== --------------ms040205010807090402010709-- From rees@umich.edu Sat Oct 27 02:56:28 2007 From: rees@umich.edu (Jim Rees) Date: Fri, 26 Oct 2007 21:56:28 -0400 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release available In-Reply-To: <472286C3.3030004@secure-endpoints.com> References: <20071026234628.GA17913@citi.umich.edu> <472286C3.3030004@secure-endpoints.com> Message-ID: <20071027015628.GA28732@citi.umich.edu> Jeffrey Altman wrote: Works for me!!! It seems to be ok here http://www.openafs.org/release/latest.html But I find the framed version so annoying that I don't use it. Until now I assumed the frameless version had the same content in an easier to use form, but that's apparently not the case, as the frameless version is out of date: http://www.openafs.org/frameless/release/latest.html We've been talking about the new web site forever, but nothing has changed. Maybe we should start by getting rid of the frames, and fix the rest of it later. If we wait until the new web site is perfect, it will never happen. From jaltman@secure-endpoints.com Sat Oct 27 03:20:27 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 26 Oct 2007 22:20:27 -0400 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release available In-Reply-To: <20071027015628.GA28732@citi.umich.edu> References: <20071026234628.GA17913@citi.umich.edu> <472286C3.3030004@secure-endpoints.com> <20071027015628.GA28732@citi.umich.edu> Message-ID: <4722A06B.4020306@secure-endpoints.com> Jim Rees wrote: > Jeffrey Altman wrote: > > Works for me!!! > > It seems to be ok here > http://www.openafs.org/release/latest.html > > But I find the framed version so annoying that I don't use it. Until now I > assumed the frameless version had the same content in an easier to use form, > but that's apparently not the case, as the frameless version is out of date: > http://www.openafs.org/frameless/release/latest.html The frameless version works for me as well. > We've been talking about the new web site forever, but nothing has changed. > Maybe we should start by getting rid of the frames, and fix the rest of it > later. If we wait until the new web site is perfect, it will never happen. The same people who do not have time to work on the content for the new web site do not have time to work on the old web site. Jeffrey Altman From hanke@rzg.mpg.de Sat Oct 27 17:10:18 2007 From: hanke@rzg.mpg.de (Christof Hanke) Date: Sat, 27 Oct 2007 19:10:18 +0300 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release available In-Reply-To: References: Message-ID: <472362EA.3060206@rzg.mpg.de> Derrick J Brashear wrote: > The OpenAFS Gatekeepers announce the availability of OpenAFS version > 1.4.5. Source files and available binaries can be accessed via the web at: > > http://www.openafs.org/dl/openafs/1.4.5/ > > or via AFS at: > > /afs/grand.central.org/software/openafs/1.4.5/ > \\afs\grand.central.org\software\openafs\1.4.5\ > Good stuff. I just want to announce that SuSE rpms can be found on the buildservice: http://download.opensuse.org/repositories/filesystems/// , where distributions are : SUSE_Linux_10.0, SUSE_Linux_10.1, openSUSE_10.2, openSUSE_10.3, SLES_9 and SLE_10 architectures are i586 and x86_64. you might also use : http://software.opensuse.org/search It is possible to integrate the buildservice-repository also in the package-manager of your choice. Check out the tutorial. There are two versions: "openafs", in which the paths integrates in the OS-tree and "openafs-transarc", which uses transarc-paths. Unfortunately, I have not packaged any binary kernel-modules, except some old standard ones. Thus, use km_afs to compile the kernel module for your present kernel. If you stumble across anything awry, just shout at me. I guess future versions of openafs can be found there as well. T/Christof Hanke PS: A note to packagers of other distributions: It is indeed possible to use this buildservice to package fedora, ubuntu, debian, mandriva and some other distributions. Thus, if your short on hardware you might give it a try. The only thing I haven't figured out is how to build rpms depending on rpm of different versions (that's why there are no binary kernel module packages). From tmaher@watson.org Sat Oct 27 20:57:03 2007 From: tmaher@watson.org (Tom Maher) Date: Sat, 27 Oct 2007 12:57:03 -0700 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release available In-Reply-To: <20071027015628.GA28732@citi.umich.edu> References: <20071026234628.GA17913@citi.umich.edu> <472286C3.3030004@secure-endpoints.com> <20071027015628.GA28732@citi.umich.edu> Message-ID: http://www.openafs.org/release/1.4.5/index-solaris-10.html and http://www.openafs.org/frameless/release/1.4.5/index-solaris-10.html both give a big fat 404 On 10/26/07, Jim Rees wrote: > Jeffrey Altman wrote: > > Works for me!!! > > It seems to be ok here > http://www.openafs.org/release/latest.html > > But I find the framed version so annoying that I don't use it. Until now I > assumed the frameless version had the same content in an easier to use form, > but that's apparently not the case, as the frameless version is out of date: > http://www.openafs.org/frameless/release/latest.html > > We've been talking about the new web site forever, but nothing has changed. > Maybe we should start by getting rid of the frames, and fix the rest of it > later. If we wait until the new web site is perfect, it will never happen. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Tom Maher From deengert@anl.gov Sat Oct 27 21:32:21 2007 From: deengert@anl.gov (Douglas E. Engert) Date: Sat, 27 Oct 2007 15:32:21 -0500 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.5 release available In-Reply-To: References: <20071026234628.GA17913@citi.umich.edu> <472286C3.3030004@secure-endpoints.com> <20071027015628.GA28732@citi.umich.edu> Message-ID: <4723A055.2080608@anl.gov> Tom Maher wrote: > http://www.openafs.org/release/1.4.5/index-solaris-10.html > and > http://www.openafs.org/frameless/release/1.4.5/index-solaris-10.html > both give a big fat 404 I get the 404 too. I suspect it will be fixed soon, I sent in 20 minutes before the announcement, both a sun4x_510 and a sun4x_510 with namei, both with the aklog using Solaris Kerberos, and tested on update 4. > > > On 10/26/07, Jim Rees wrote: >> Jeffrey Altman wrote: >> >> Works for me!!! >> >> It seems to be ok here >> http://www.openafs.org/release/latest.html >> >> But I find the framed version so annoying that I don't use it. Until now I >> assumed the frameless version had the same content in an easier to use form, >> but that's apparently not the case, as the frameless version is out of date: >> http://www.openafs.org/frameless/release/latest.html >> >> We've been talking about the new web site forever, but nothing has changed. >> Maybe we should start by getting rid of the frames, and fix the rest of it >> later. If we wait until the new web site is perfect, it will never happen. >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From geek+afs@qatar.cmu.edu Mon Oct 29 07:48:34 2007 From: geek+afs@qatar.cmu.edu (Brian Gallew) Date: Mon, 29 Oct 2007 09:48:34 +0300 Subject: [OpenAFS] Odd mountpoint behaviour. Message-ID: <47258242.9010802@qatar.cmu.edu> I have a mysterious missing volume. In /afs/qatar.cmu.edu/system/gamma/sun4x_s10/nos I have two mount points: 1067 nos > fs lsm * '003' is a mount point for volume '#sun4s10.os.003' '004' is a mount point for volume '#sun4s10.os.004' However, only one of them is accessible: 1068 nos > ls 003 ls: 003: No such device 1070 nos > ls -l total 2 ?---------+ ? ? ? ? ? 003 drwxr-xr-x 22 root root 2048 Jul 28 2006 004/ This would be perfectly normal if sun4s10.os.003 were missing, but: 1063 nos > vos examine sun4s10.os.003 sun4s10.os.003 1971975579 RW 101471 K On-line AFS1.qatar.cmu.edu /vicepb RWrite 1971975579 ROnly 1971975580 Backup 0 MaxQuota 0 K Creation Sun Oct 28 13:54:24 2007 Copy Sun Oct 28 13:54:12 2007 Backup Tue Feb 13 03:30:50 2007 Last Update Thu Sep 14 00:38:20 2006 0 accesses in the past day (i.e., vnode references) RWrite: 1971975579 ROnly: 1971975580 number of sites -> 3 server AFS1.qatar.cmu.edu partition /vicepb RW Site server AFS1.qatar.cmu.edu partition /vicepb RO Site server AFS2.qatar.cmu.edu partition /vicepb RO Site I've done the obvious things like looking for vice cache corruption (cleared cache on multiple machines, no joy). So, I'm stumped. Any ideas? From jaltman@secure-endpoints.com Mon Oct 29 13:53:56 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 29 Oct 2007 08:53:56 -0400 Subject: [OpenAFS] Odd mountpoint behaviour. In-Reply-To: <47258242.9010802@qatar.cmu.edu> References: <47258242.9010802@qatar.cmu.edu> Message-ID: <4725D7E4.80100@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms070206080800080403090006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Version of OpenAFS? Version of Operating System? Brian Gallew wrote: > I have a mysterious missing volume. In > /afs/qatar.cmu.edu/system/gamma/sun4x_s10/nos I have two mount points: > 1067 nos > fs lsm * > '003' is a mount point for volume '#sun4s10.os.003' > '004' is a mount point for volume '#sun4s10.os.004' > > However, only one of them is accessible: > 1068 nos > ls 003 > ls: 003: No such device > > 1070 nos > ls -l > total 2 > ?---------+ ? ? ? ? ? 003 > drwxr-xr-x 22 root root 2048 Jul 28 2006 004/ > > This would be perfectly normal if sun4s10.os.003 were missing, but: > 1063 nos > vos examine sun4s10.os.003 > sun4s10.os.003 1971975579 RW 101471 K On-line > AFS1.qatar.cmu.edu /vicepb > RWrite 1971975579 ROnly 1971975580 Backup 0 > MaxQuota 0 K > Creation Sun Oct 28 13:54:24 2007 > Copy Sun Oct 28 13:54:12 2007 > Backup Tue Feb 13 03:30:50 2007 > Last Update Thu Sep 14 00:38:20 2006 > 0 accesses in the past day (i.e., vnode references) > > RWrite: 1971975579 ROnly: 1971975580 > number of sites -> 3 > server AFS1.qatar.cmu.edu partition /vicepb RW Site > server AFS1.qatar.cmu.edu partition /vicepb RO Site > server AFS2.qatar.cmu.edu partition /vicepb RO Site > > I've done the obvious things like looking for vice cache corruption > (cleared cache on multiple machines, no joy). So, I'm stumped. Any ideas? > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --------------ms070206080800080403090006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMjkxMjUzNTZaMCMGCSqGSIb3DQEJBDEWBBRuxNcX q+goRZtrOi5AwBwnKFjdfjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAi2dO8L9iZwFv4ozrggS+M1RQQUOigsMDztYlNfvwWgPVio9VU28K BGF3oBw9H8lM4IxNsmOzEE4qIMtdiNw8I8beV3Clpmwry0RmTgWpxOgFZlch0hnviCM9AvDl ZTAgW64Mun8uKSDFCIlVof3fP3HMomBnB9pFCABIkBgFy6R3pVvEJoasuf4pCPF3osZkLkE3 D6QAfYiDSIv3AO0nD4VEr6I4pA1CRarDrvTLmnwnHsJqQsb63fbmmyQQdgMhq/U1xZ6oRfI7 4F+Zz5e+jLkYU0XYTRlXs9D7mn++zxRsiwpuhW8AGq02ZsfS15unhPMDTGCx90jRFoefdLOE 4AAAAAAAAA== --------------ms070206080800080403090006-- From geek+afs@qatar.cmu.edu Mon Oct 29 14:16:03 2007 From: geek+afs@qatar.cmu.edu (Brian Gallew) Date: Mon, 29 Oct 2007 16:16:03 +0300 Subject: [OpenAFS] Odd mountpoint behaviour. In-Reply-To: <4725D7E4.80100@secure-endpoints.com> References: <47258242.9010802@qatar.cmu.edu> <4725D7E4.80100@secure-endpoints.com> Message-ID: <4725DD13.1080709@qatar.cmu.edu> Jeffrey Altman wrote: > Version of OpenAFS? > Version of Operating System? > It works correctly on Solaris8 (OpenAFS-1.2.11) The problem is exhibited on two different linux systems (RHEL AS4/OpenAFS-1.5.8 and Andrew FC3/1.3?) and a Solaris10 system (OpenAFS-1.4.1). My AFS servers are RHEL WS3 systems running OpenAFS-1.4.4. From shadow@gmail.com Mon Oct 29 15:44:33 2007 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 29 Oct 2007 10:44:33 -0400 Subject: [OpenAFS] Odd mountpoint behaviour. In-Reply-To: <4725DD13.1080709@qatar.cmu.edu> References: <47258242.9010802@qatar.cmu.edu> <4725D7E4.80100@secure-endpoints.com> <4725DD13.1080709@qatar.cmu.edu> Message-ID: ------=_Part_4114_10145204.1193669073734 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/29/07, Brian Gallew wrote: > > Jeffrey Altman wrote: > > Version of OpenAFS? > > Version of Operating System? > > > It works correctly on Solaris8 (OpenAFS-1.2.11) > The problem is exhibited on two different linux systems (RHEL > AS4/OpenAFS-1.5.8 and Andrew FC3/1.3?) and a Solaris10 system > (OpenAFS-1.4.1). > > My AFS servers are RHEL WS3 systems running OpenAFS-1.4.4. can you try something modern on any of the clients? any??? ------=_Part_4114_10145204.1193669073734 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/29/07, Brian Gallew <geek+afs@qatar.cmu.edu> wrote:
Jeffrey Altman wrote:
> Version of OpenAFS?
> Version of Operating System?
>
It works correctly on Solaris8 (OpenAFS-1.2.11)
The problem is exhibited on two different linux systems (RHEL
AS4/OpenAFS- 1.5.8 and Andrew FC3/1.3?) and a Solaris10 system
(OpenAFS-1.4.1).

My AFS servers are RHEL WS3 systems running OpenAFS-1.4.4.

can you try something modern on any of the clients? any???

 


------=_Part_4114_10145204.1193669073734-- From Jason.Harper@asu.edu Mon Oct 29 17:41:16 2007 From: Jason.Harper@asu.edu (Jason Harper) Date: Mon, 29 Oct 2007 09:41:16 -0700 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 Message-ID: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> This is a multi-part message in MIME format. ------_=_NextPart_001_01C81A4A.86D430A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello =20 Are there plans to release the src.rpm for rhel4 and rhel5? Or am I missing it? =20 Thanks Jason =20 ------_=_NextPart_001_01C81A4A.86D430A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello

 

Are there plans to release the src.rpm for rhel4 = and rhel5?   Or am I missing it?

 

Thanks

Jason

 

------_=_NextPart_001_01C81A4A.86D430A3-- From sxw@inf.ed.ac.uk Mon Oct 29 17:45:01 2007 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 29 Oct 2007 16:45:01 +0000 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> Message-ID: <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> On 29 Oct 2007, at 16:41, Jason Harper wrote: > Are there plans to release the src.rpm for rhel4 and rhel5? Or am > I missing it? The RHEL5 SRPM is identical to the the Fedora Core ones. S. From jblaine@kickflop.net Mon Oct 29 18:09:26 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Mon, 29 Oct 2007 13:09:26 -0400 Subject: [OpenAFS] kaserver.DB0 converted, no success authenticating Message-ID: <472613C6.8000602@kickflop.net> Again, pardon the Kerberos/OpenAFS dual nature of this request. I am posting here because it certainly seems related to the conversion and I'd eventually like to document every hurdle of this ping-pong bout. I dumped kaserver.DB0, removed the AuthServer, afs, and krbtgt principals at the top of the file, and loaded it into my KDC. I confirmed the new principals' existence via listprincs. I am no longer able to authenticate as jblaine: kadmin.local: getprinc jblaine Principal: jblaine@RCF.FOO.COM Expiration date: Wed Dec 30 19:00:00 EST 2037 Last password change: [never] Password expiration date: [none] Maximum ticket life: 14 days 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Oct 29 12:37:53 EDT 2007 (jblaine@RCF.FOO.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 5, DES cbc mode with CRC-32, AFS version 3 Attributes: Policy: [none] jblaine% /usr/kerberos/bin/kinit kinit(v5): Password incorrect while getting initial credentials jblaine% Oct 29 12:58:13 silmaril krb5kdc[13245](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) xxx.xx.11.213: DECRYPT_CLIENT_KEY: jblaine@RCF.FOO.COM for krbtgt/RCF.FOO.COM@RCF.FOO.COM, Decrypt integrity check failed From kenh@cmf.nrl.navy.mil Mon Oct 29 18:21:39 2007 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Mon, 29 Oct 2007 13:21:39 -0400 Subject: [OpenAFS] kaserver.DB0 converted, no success authenticating In-Reply-To: <472613C6.8000602@kickflop.net> Message-ID: <200710291721.l9THLdVs011274@ginger.cmf.nrl.navy.mil> >Oct 29 12:58:13 silmaril krb5kdc[13245](info): AS_REQ (7 etypes {18 17 >16 23 1 3 2}) xxx.xx.11.213: DECRYPT_CLIENT_KEY: jblaine@RCF.FOO.COM for >krbtgt/RCF.FOO.COM@RCF.FOO.COM, Decrypt integrity check failed One little thing I always forget about afs2k5db .... it currently only works if your master key is single-DES (in theory this isn't hard to fix, but see previous comments about time, interest, etc etc). Judging by this error, the client keys are not encrypted properly in the database. I am guessing that your K/M principal is something other than single-DES. --Ken From kwc@citi.umich.edu Mon Oct 29 18:39:28 2007 From: kwc@citi.umich.edu (Kevin Coffman) Date: Mon, 29 Oct 2007 13:39:28 -0400 Subject: [OpenAFS] kaserver.DB0 converted, no success authenticating In-Reply-To: <200710291721.l9THLdVs011274@ginger.cmf.nrl.navy.mil> References: <472613C6.8000602@kickflop.net> <200710291721.l9THLdVs011274@ginger.cmf.nrl.navy.mil> Message-ID: <4d569c330710291039n42a43ad6g3d381cf706482774@mail.gmail.com> On 10/29/07, Ken Hornstein wrote: > >Oct 29 12:58:13 silmaril krb5kdc[13245](info): AS_REQ (7 etypes {18 17 > >16 23 1 3 2}) xxx.xx.11.213: DECRYPT_CLIENT_KEY: jblaine@RCF.FOO.COM for > >krbtgt/RCF.FOO.COM@RCF.FOO.COM, Decrypt integrity check failed > > One little thing I always forget about afs2k5db .... it currently only > works if your master key is single-DES (in theory this isn't hard to fix, > but see previous comments about time, interest, etc etc). Judging by > this error, the client keys are not encrypted properly in the database. > I am guessing that your K/M principal is something other than single-DES. Could changing realm names be another possibility? Jeff, are you using the same realm name in your KDC as in the kaserver? From jblaine@kickflop.net Mon Oct 29 18:55:55 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Mon, 29 Oct 2007 13:55:55 -0400 Subject: [OpenAFS] kaserver.DB0 converted, no success authenticating In-Reply-To: <4d569c330710291039n42a43ad6g3d381cf706482774@mail.gmail.com> References: <472613C6.8000602@kickflop.net> <200710291721.l9THLdVs011274@ginger.cmf.nrl.navy.mil> <4d569c330710291039n42a43ad6g3d381cf706482774@mail.gmail.com> Message-ID: <47261EAB.6020602@kickflop.net> Kevin Coffman wrote: > On 10/29/07, Ken Hornstein wrote: >>> Oct 29 12:58:13 silmaril krb5kdc[13245](info): AS_REQ (7 etypes {18 17 >>> 16 23 1 3 2}) xxx.xx.11.213: DECRYPT_CLIENT_KEY: jblaine@RCF.FOO.COM for >>> krbtgt/RCF.FOO.COM@RCF.FOO.COM, Decrypt integrity check failed >> One little thing I always forget about afs2k5db .... it currently only >> works if your master key is single-DES (in theory this isn't hard to fix, >> but see previous comments about time, interest, etc etc). Judging by >> this error, the client keys are not encrypted properly in the database. >> I am guessing that your K/M principal is something other than single-DES. Thanks Ken and Kevin. > Could changing realm names be another possibility? Jeff, are you > using the same realm name in your KDC as in the kaserver? Same realm. Yes, the K/M principal is single and triple DES'd. How does one go about deleting one of K/M's keys in DB without shooting oneself in the foot? From rich@nd.edu Mon Oct 29 19:15:44 2007 From: rich@nd.edu (Rich Sudlow) Date: Mon, 29 Oct 2007 14:15:44 -0400 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> Message-ID: <47262350.40100@nd.edu> Simon Wilkinson wrote: > > On 29 Oct 2007, at 16:41, Jason Harper wrote: >> Are there plans to release the src.rpm for rhel4 and rhel5? Or am I >> missing it? > The RHEL5 SRPM is identical to the the Fedora Core ones. I found some source files missing from the FC srpms - I installed the 1.4.4 srpms and then 1.4.5 on top and then it worked fine for me for RH4. Rich > > S. > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Rich Sudlow University of Notre Dame Center for Research Computing 128 Information Technology Center PO Box 539 Notre Dame, IN 46556-0539 (574) 631-7258 office phone (574) 631-9283 office fax From sxw@inf.ed.ac.uk Mon Oct 29 19:22:28 2007 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 29 Oct 2007 18:22:28 +0000 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: <47262350.40100@nd.edu> References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> <47262350.40100@nd.edu> Message-ID: On 29 Oct 2007, at 18:15, Rich Sudlow wrote: > > I found some source files missing from the FC srpms - I installed > the 1.4.4 srpms and then 1.4.5 on top and then it worked fine > for me for RH4. That shouldn't be happening, as anything the RPM references in the SOURCE directory should be packaged. A number of the builds I did were from a bare rpm build directory too, so I'm surprised I didn't notice this. Which files were missing? S. From rich@nd.edu Mon Oct 29 19:35:47 2007 From: rich@nd.edu (Rich Sudlow) Date: Mon, 29 Oct 2007 14:35:47 -0400 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> <47262350.40100@nd.edu> Message-ID: <47262803.7070601@nd.edu> Simon Wilkinson wrote: > > On 29 Oct 2007, at 18:15, Rich Sudlow wrote: > >> >> I found some source files missing from the FC srpms - I installed >> the 1.4.4 srpms and then 1.4.5 on top and then it worked fine >> for me for RH4. > > That shouldn't be happening, as anything the RPM references in the > SOURCE directory should be packaged. A number of the builds I did were > from a bare rpm build directory too, so I'm surprised I didn't notice > this. Which files were missing? The files referenced below # Populate /usr/vice/etc uve=$RPM_BUILD_ROOT%{_prefix}/vice/etc install -p -m 644 src/packaging/RedHat/openafs-ThisCell $uve/ThisCell install -p -m 644 %{SOURCE20} $uve/CellServDB.dist install -p -m 644 src/packaging/RedHat/openafs-cacheinfo $uve/cacheinfo I figured it was just something different in newer RH & FC versions. Rich > > S. > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- Rich Sudlow University of Notre Dame Center for Research Computing 128 Information Technology Center PO Box 539 Notre Dame, IN 46556-0539 (574) 631-7258 office phone (574) 631-9283 office fax From shadow@gmail.com Mon Oct 29 19:59:29 2007 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 29 Oct 2007 14:59:29 -0400 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: <47262803.7070601@nd.edu> References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> <47262350.40100@nd.edu> <47262803.7070601@nd.edu> Message-ID: ------=_Part_5161_18663570.1193684369149 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > The files referenced below > > # Populate /usr/vice/etc > uve=$RPM_BUILD_ROOT%{_prefix}/vice/etc > install -p -m 644 src/packaging/RedHat/openafs-ThisCell $uve/ThisCell > install -p -m 644 %{SOURCE20} $uve/CellServDB.dist > install -p -m 644 src/packaging/RedHat/openafs-cacheinfo $uve/cacheinfo > > I figured it was just something different in newer RH & FC versions. use the newer specfile? ------=_Part_5161_18663570.1193684369149 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

The files referenced below

# Populate /usr/vice/etc
uve=$RPM_BUILD_ROOT%{_prefix}/vice/etc
install -p -m 644 src/packaging/RedHat/openafs-ThisCell $uve/ThisCell
install -p -m 644 %{SOURCE20} $uve/CellServDB.dist
install -p -m 644 src/packaging/RedHat/openafs-cacheinfo $uve/cacheinfo

I figured it was just something different in newer RH & FC versions.

use the newer specfile?



------=_Part_5161_18663570.1193684369149-- From Jason.Harper@asu.edu Mon Oct 29 20:03:15 2007 From: Jason.Harper@asu.edu (Jason Harper) Date: Mon, 29 Oct 2007 12:03:15 -0700 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> <47262350.40100@nd.edu> Message-ID: <037FF41095AD394DB28A3991559A0FB404CDD30B@EX04.asurite.ad.asu.edu> Simon Wilkinson wrote: > On 29 Oct 2007, at 18:15, Rich Sudlow wrote: > > I found some source files missing from the FC srpms - I installed > > the 1.4.4 srpms and then 1.4.5 on top and then it worked fine > > for me for RH4. >=20 > That shouldn't be happening, as anything the RPM references in the =20 > SOURCE directory should be packaged. A number of the builds I did =20 > were from a bare rpm build directory too, so I'm surprised I didn't =20 > notice this. Which files were missing? openafs-kvers-is.sh for one appears to be missing: # rpmbuild --rebuild --target=3Di686 openafs-1.4.5-fc7.1.src.rpm=20 Installing openafs-1.4.5-fc7.1.src.rpm warning: user sxw does not exist - using root warning: user sxw does not exist - using root warning: user sxw does not exist - using root warning: user sxw does not exist - using root Building target platforms: i686 Building for target i686 sh: /usr/src/redhat/SOURCES/openafs-kvers-is.sh: No such file or directory sh: /usr/src/redhat/SOURCES/openafs-kvers-is.sh: No such file or directory error: /usr/src/redhat/SPECS/openafs.spec:124: parseExpressionBoolean returns -1 error: Name field must be present in package: (main package) error: Version field must be present in package: (main package) error: Release field must be present in package: (main package) error: Summary field must be present in package: (main package) error: Group field must be present in package: (main package) error: License field must be present in package: (main package) I took a guess and symlinked that to openafs-kernel-version.sh and then I get a failed build dependency on kernel-source which I believe has been replaced by kernel-devel in rhel5. I then tried adding --nodeps which resulted in a lot of compiling, but then it ran into other errors while trying to package up the rpms. All I'm really trying to do is build the kernel module for the latest kernel so I can install/use the OpenAFS client. Jason From kenh@cmf.nrl.navy.mil Mon Oct 29 20:05:43 2007 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Mon, 29 Oct 2007 15:05:43 -0400 Subject: [OpenAFS] kaserver.DB0 converted, no success authenticating In-Reply-To: <47261EAB.6020602@kickflop.net> Message-ID: <200710291905.l9TJ5iCY015318@ginger.cmf.nrl.navy.mil> >> Could changing realm names be another possibility? Jeff, are you >> using the same realm name in your KDC as in the kaserver? Just as a side note: that is definately not the problem here. This is evident by the KDC log message mentioning "DECRYPT_CLIENT_KEY" - that can only occur if the principal keys are encrypted incorrectly. The confusing part is that "Decrypt integrity check failed" is passed back to the client and it interprets it as "Password incorrect", which is confusing. >Yes, the K/M principal is single and triple DES'd. > >How does one go about deleting one of K/M's keys in DB >without shooting oneself in the foot? Short answer: you don't. There is currently not a good way to change the enctype of the master key (you can _change_ the key, but it has to have the same enctype). Just deleting the triple-DES key isn't good enough, as your existing keys will then not be able to be decrypted. This may have changed more recently, so I could be wrong. I tried to change my master key enctype once, but it was used in enough places that it was very hard, so I gave up. I think your easiest solution is to fix afs2k5db so it works with different master key enctypes. Like I said, IN THEORY this should be simple. Second easiest: redo your realm with only a single-DES key (it all depends on your realm setup as to which one you find easier). --Ken From shadow@gmail.com Mon Oct 29 20:08:14 2007 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 29 Oct 2007 15:08:14 -0400 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: <037FF41095AD394DB28A3991559A0FB404CDD30B@EX04.asurite.ad.asu.edu> References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> <47262350.40100@nd.edu> <037FF41095AD394DB28A3991559A0FB404CDD30B@EX04.asurite.ad.asu.edu> Message-ID: ------=_Part_5206_20826242.1193684894404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/29/07, Jason Harper wrote: > > Simon Wilkinson wrote: > > > On 29 Oct 2007, at 18:15, Rich Sudlow wrote: > > > I found some source files missing from the FC srpms - I installed > > > the 1.4.4 srpms and then 1.4.5 on top and then it worked fine > > > for me for RH4. > > > > That shouldn't be happening, as anything the RPM references in the > > SOURCE directory should be packaged. A number of the builds I did > > were from a bare rpm build directory too, so I'm surprised I didn't > > notice this. Which files were missing? > > openafs-kvers-is.sh for one appears to be missing: > > # rpmbuild --rebuild --target=i686 openafs-1.4.5-fc7.1.src.rpm > Installing openafs-1.4.5-fc7.1.src.rpm > warning: user sxw does not exist - using root > warning: user sxw does not exist - using root > warning: user sxw does not exist - using root > warning: user sxw does not exist - using root > Building target platforms: i686 > Building for target i686 > sh: /usr/src/redhat/SOURCES/openafs-kvers-is.sh: No such file or > directory > sh: /usr/src/redhat/SOURCES/openafs-kvers-is.sh: No such file or > directory > error: /usr/src/redhat/SPECS/openafs.spec:124: parseExpressionBoolean > returns -1 > error: Name field must be present in package: (main package) > error: Version field must be present in package: (main package) > error: Release field must be present in package: (main package) > error: Summary field must be present in package: (main package) > error: Group field must be present in package: (main package) > error: License field must be present in package: (main package) > > > I took a guess and symlinked that to openafs-kernel-version.sh and then > I get a failed build dependency on kernel-source which I believe has > been replaced by kernel-devel in rhel5. I then tried adding --nodeps > which resulted in a lot of compiling, but then it ran into other errors > while trying to package up the rpms. > > All I'm really trying to do is build the kernel module for the latest > kernel so I can install/use the OpenAFS client. > > Jason > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > ------=_Part_5206_20826242.1193684894404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/29/07, Jason Harper <Jason.Harper@asu.edu> wrote:
Simon Wilkinson wrote:

> On 29 Oct 2007, at 18:15, Rich Sudlow wrote:
> > I found some source files missing from the FC srpms - I installed
> > the 1.4.4 srpms and then 1.4.5 on top and then it worked fine
> > for me for RH4.
>
> That shouldn't be happening, as anything the RPM references in the
> SOURCE directory should be packaged. A number of the builds I did
> were from a bare rpm build directory too, so I'm surprised I didn't
> notice this. Which files were missing?

openafs-kvers-is.sh for one appears to be missing:

# rpmbuild --rebuild --target=i686 openafs-1.4.5-fc7.1.src.rpm
Installing openafs-1.4.5-fc7.1.src.rpm
warning: user sxw does not exist - using root
warning: user sxw does not exist - using root
warning: user sxw does not exist - using root
warning: user sxw does not exist - using root
Building target platforms: i686
Building for target i686
sh: /usr/src/redhat/SOURCES/openafs-kvers-is.sh: No such file or
directory
sh: /usr/src/redhat/SOURCES/openafs-kvers-is.sh: No such file or
directory
error: /usr/src/redhat/SPECS/openafs.spec:124: parseExpressionBoolean
returns -1
error: Name field must be present in package: (main package)
error: Version field must be present in package: (main package)
error: Release field must be present in package: (main package)
error: Summary field must be present in package: (main package)
error: Group field must be present in package: (main package)
error: License field must be present in package: (main package)


I took a guess and symlinked that to openafs-kernel-version.sh and then
I get a failed build dependency on kernel-source which I believe has
been replaced by kernel-devel in rhel5.  I then tried adding --nodeps
which resulted in a lot of compiling, but then it ran into other errors
while trying to package up the rpms.

All I'm really trying to do is build the kernel module for the latest
kernel so I can install/use the OpenAFS client.

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

------=_Part_5206_20826242.1193684894404-- From sxw@inf.ed.ac.uk Mon Oct 29 20:13:32 2007 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 29 Oct 2007 19:13:32 +0000 Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: <037FF41095AD394DB28A3991559A0FB404CDD30B@EX04.asurite.ad.asu.edu> References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> <96629D2A-928C-4520-AF70-B4091F7068E2@inf.ed.ac.uk> <47262350.40100@nd.edu> <037FF41095AD394DB28A3991559A0FB404CDD30B@EX04.asurite.ad.asu.edu> Message-ID: <1059D94F-7884-4D73-83A7-2553AB5AD625@inf.ed.ac.uk> On 29 Oct 2007, at 19:03, Jason Harper wrote: > All I'm really trying to do is build the kernel module for the latest > kernel so I can install/use the OpenAFS client. The missing file is in src/packaging/RedHat/openafs-kvers-is.sh directory of the distribution - a quick fix is to just copy it from there into your SOURCES directory However, if you're trying to build a new kernel module to go with the OpenAFS 1.4.5 Fedora or RHEL5 builds, you'll need to build with the '--define fedorakmod 1' option, in order to build a new 'kmod-*' style kernel module that's compatible with the rest of the userspace RPMs. If you do this, you won't need the 'openafs-kvers-is.sh' file. Cheers, Simon From jblaine@kickflop.net Mon Oct 29 20:19:10 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Mon, 29 Oct 2007 15:19:10 -0400 Subject: [OpenAFS] Password transition to krb5 - your methods? In-Reply-To: <200710261211.l9QCBE25017312@ginseng.hep.wisc.edu> References: <200710251636.l9PGaSKX005595@ginger.cmf.nrl.navy.mil> <4720C93E.2060304@kickflop.net> <472113F9.4060704@kickflop.net> <200710261211.l9QCBE25017312@ginseng.hep.wisc.edu> Message-ID: <4726322E.1040601@kickflop.net> rader@ginseng.hep.wisc.edu wrote: > Did you try this?? > > - build krb5 1.3.x No: > > MIT Kerberos 1.3 : Fails to build: > > > > /blah/krb5-1.3/src/include/k5-int.h:1783: > > error: parse error before "krb5_donot_replay" But I got MIT krb5 1.4.4 to build so that part's done. Thanks From scs@umich.edu Mon Oct 29 22:45:22 2007 From: scs@umich.edu (Steve Simmons) Date: Mon, 29 Oct 2007 17:45:22 -0400 Subject: [OpenAFS] Job opening at Umich Message-ID: Advance apologies to anybody who gets more than 1 copy; this is going to a number of lists. We have an opening for a programmer in our group at UM. The details of the posting are at the bottom, so you don't need to go hit our web page to see it. If you really must, see the posting, you'll need to follow this convoluted path: Open http://www.umich.edu/~jobs Hit the link for 'External Candidates' Under 'Visit as guest', hit the button 'Visit today' Under 'Search for jobs' hit 'Keyword search' Enter "ITCS" as the keyword and hit 'Search' A set of openings will come up, The one in our group is #12717 "Software Engineer Senior/Intermediate". Select that for details. If you're interested, hit the 'Apply for Job' button and go through the pain of entering your resume/etc into the University system. A few things I can say about the job aside from what's in the post - It's in our group. That means you get to work with a bunch of smart, dedicated folks doing a mix of sysadmin, programming, development, and maintenance. I like our group a lot, and I'm pretty picky. :-) For a while one of the primary tasks will be working with me on kerberos-related stuff, esp. taking Umich patches to kerberos and cleaning/upgrading/changing them in such as way as to still meet our needs but be acceptable to the kerberos community for inclusion in standard MIT kerberos. There is the inevitable 'whatever else comes up' component. C'est le guerre, caveat emptor, etc. The on-call schedule is not onerous. You get a week of on-call once every five or six weeks. On a good week little or nothing happens; in my experience 2 out of 3 weeks are good weeks. The others vary from slightly irritating to "Holy Shit!" University benefits can't be beat; inexpensive and comprehensive. 40 hours per week means 40 hours per week. And unless I'm misunderstanding things, since this is an exempt (salaried) position, you get 2 vacation days per month. Plus four more days at Christmas. No partridges, no pear trees. Sorry. On the other hand, the University has a 401k-equivalent package that they will match 2:1 through the first 5% of your salary; this is equivalent to another 10% of your salary. Do not be dismayed by the 'Desired Qualifications' list. It describes the perfect person. On the other hand, if you can't meet most of the 'Minimum Requirements' please don't waste either of our time applying. If you apply (especially if you're not someone I'd immediately recognize) drop me a note directly so I can keep an eye open for it. Callbacks and interviews will not start before the position closes Nov. 25 unless we get so many qualified applicants we have to start interviewing early. So don't expect an immediate response. Full description follows: ------- Market Title: Software Engineer Senior/Intermediate Department: ITCS - Information Technology Central Services FLSA: Exempt Salary Range: $40,000 - $70,000 Hours/Week: 40 Hours Shift/Hours/Days: Days, Monday thru Friday Posting Dates: 10/25/07 thru 11/25/07 In order to receive full consideration, we are requesting that each candidate provide an ending salary with each position listed on your resume, and also please state in your cover letter what your salary expectations are for this position. This information will be very helpful in the candidate selection process. DUTIES: Provides technical advice and leadership to Institutional File Service and General Purpose Computing Cycles team members. Mentors junior staff and helps to provide for long term service support and stability. Works with members of campus community to facilitate service offerings, planning and direction. Facilitates community support and coordination with other parts of the organization. Performs high level analysis and debugging of service issues. Coordinates and enables ongoing support and maintenance of GPCC and IFS services not limited to login, statistics, mfile, sftp, AFS,DNS and related support systems. Plans and coordinates upgrades to infrastructure services. Mentors and assists staff in doing the same. Participates and facilitates group efforts designing new products and services; capacity planning, product roll-outs and relationships with other units. Work on C coding projects relating to OpenAFS, Kerberos and other UMCE technologies in conjunction with colleagues and other senior level staff. Reviews, diagnoses and monitors issues with these systems and their implementation. Performs analysis of service for performance enhancements, security concerns and appropriate scaling and implementation. ***This position will require some on-call activity outside of regular business hours.*** Job Requirements: MINIMUM QUALIFICATIONS: Bachelor's degree in the field of information systems, computer science, mathematics, statistics or an equivalent combination of education and experience (five to seven years of experience in computer related fields). Significant experience with Linux Operating systems administration. Experience with UNIX tools such as Perl, C/C++, Lisp, Lex, Yacc, shell scripting, awk, make and source code control; extensive experience with AFS, Kerberos, Linux, and DNS/Bind. Strong C coding skills and experience working on large scale open source C projects as part of a team. Strong oral and written communication skills; strong analytical and problem resolution skills; demonstrated leadership ability and the ability to work as a member of a team. DESIRED QUALIFICATIONS: Seven to ten years experience. Familiarity with the University of Michigan Computer Environment. Familiarity with UM and ITCS organization. Experience with Statistics, Networking, Linux security, and large multiuser UNIX environments. Solid planning and organizational skills, ability to take healthy initiatives, mentoring and coaching skills. Direct experience doing C coding work relating to OpenAFS, Kerberos or similar technologies. Experience with applications administration in a large site distributed environment; experience with software distribution techniques in a large-site environment with a particular emphasis on radmind. From shadow@dementia.org Tue Oct 30 02:40:47 2007 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 29 Oct 2007 21:40:47 -0400 (EDT) Subject: [OpenAFS] 1.4.5 SRPMs for rhel4/5 In-Reply-To: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> References: <037FF41095AD394DB28A3991559A0FB404CDD272@EX04.asurite.ad.asu.edu> Message-ID: the rhel4 srpm is up. later on i will link it through elsewhere. On Mon, 29 Oct 2007, Jason Harper wrote: > Hello > > > > Are there plans to release the src.rpm for rhel4 and rhel5? Or am I > missing it? > > > > Thanks > > Jason > > > > From geek+afs@qatar.cmu.edu Tue Oct 30 06:20:16 2007 From: geek+afs@qatar.cmu.edu (Brian Gallew) Date: Tue, 30 Oct 2007 08:20:16 +0300 Subject: [OpenAFS] Odd mountpoint behaviour. In-Reply-To: References: <47258242.9010802@qatar.cmu.edu> Message-ID: <4726BF10.2050306@qatar.cmu.edu> Chaskiel M Grundman wrote: > If you are still having this problem on an fc3 machine, let me know > which one it is, and I'll look into it. I would definitely upgrade any > machine running 1.5.8 though (and use 1.4.5 unless you need a 1.5 > specific feature). > I'm having this problem on all of my FC3 machines, which should be running identical version with what you are running Chaskiel. And I only noticed the problem when I was trying to build Solaris10 machines since they reference the volume in question. The box running 1.5.8 is my own, personal RHEL box, so I can update AFS on there as I choose. I'll do that now. From jblaine@kickflop.net Tue Oct 30 13:25:10 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Tue, 30 Oct 2007 08:25:10 -0400 Subject: [OpenAFS] 'afs' principal Message-ID: <472722A6.7090904@kickflop.net> Something I've never been very clear on as part of the conversion to Kerberos 5: The whole asetkey and afs principal operation. Could anyone explain what is going on there in detail for my (and everyone's) understanding/documentation? From kenh@cmf.nrl.navy.mil Tue Oct 30 13:35:51 2007 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Tue, 30 Oct 2007 08:35:51 -0400 Subject: [OpenAFS] 'afs' principal In-Reply-To: <472722A6.7090904@kickflop.net> Message-ID: <200710301235.l9UCZpfF011159@ginger.cmf.nrl.navy.mil> >Something I've never been very clear on as part of the >conversion to Kerberos 5: The whole asetkey and afs >principal operation. > >Could anyone explain what is going on there in detail >for my (and everyone's) understanding/documentation? Are you unclear on the concepts, or the mechanics of what you need to do? For the mechanics, you can look at the README in the AFS-Kerberos 5 migration kit (particularly steps 3 and 4). --Ken From jblaine@kickflop.net Tue Oct 30 13:38:19 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Tue, 30 Oct 2007 08:38:19 -0400 Subject: [OpenAFS] 'afs' principal In-Reply-To: <200710301235.l9UCZpfF011159@ginger.cmf.nrl.navy.mil> References: <200710301235.l9UCZpfF011159@ginger.cmf.nrl.navy.mil> Message-ID: <472725BB.7080100@kickflop.net> The concepts. The mechanics I can follow (and have). I just think it would be great to have a very clear description of what those few steps are all about (for my documentation which I intend to make as clear as possible for everyone and share). Ken Hornstein wrote: >> Something I've never been very clear on as part of the >> conversion to Kerberos 5: The whole asetkey and afs >> principal operation. >> >> Could anyone explain what is going on there in detail >> for my (and everyone's) understanding/documentation? > > Are you unclear on the concepts, or the mechanics of what you need to do? > > For the mechanics, you can look at the README in the AFS-Kerberos 5 > migration kit (particularly steps 3 and 4). > > --Ken > From jason@rampaginggeek.com Tue Oct 30 13:48:52 2007 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Tue, 30 Oct 2007 08:48:52 -0400 Subject: [OpenAFS] 'afs' principal In-Reply-To: <472722A6.7090904@kickflop.net> References: <472722A6.7090904@kickflop.net> Message-ID: <47272834.5080001@rampaginggeek.com> Jeff Blaine wrote: > Something I've never been very clear on as part of the > conversion to Kerberos 5: The whole asetkey and afs > principal operation. > > Could anyone explain what is going on there in detail > for my (and everyone's) understanding/documentation? Hi Jeff, Here is my (possibly flawed) understanding of the background: The afs@REALM kerberos principle is the crypto key that all AFS servers use to talk to once another. A client authenticates to kerberos and then runs aklog to get a ticket for the AFS service. It does this by having the asking the KDC for the afs/CELLNAME@REALM, then afs@REALM service principals using whichever is found first. The key for the afs/CELL@REALM principal or afs@REALM principal is used by all AFS servers and resides in the Keyfile. The asetkey command takes the kerberos keytab for the kerberos afs principal and stores it in the Keyfile in a format that the AFS server understands. Someone please correct me if I'm wrong. Jason From kenh@cmf.nrl.navy.mil Tue Oct 30 13:51:01 2007 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Tue, 30 Oct 2007 08:51:01 -0400 Subject: [OpenAFS] 'afs' principal In-Reply-To: <472725BB.7080100@kickflop.net> Message-ID: <200710301251.l9UCp1XT011451@ginger.cmf.nrl.navy.mil> >The concepts. The mechanics I can follow (and have). > >I just think it would be great to have a very clear >description of what those few steps are all about >(for my documentation which I intend to make as clear >as possible for everyone and share). Well ... this gets back into the overlap between Kerberos and AFS. Let me ask you this: do you understand how Kerberos works? Why you need to create service principals for Kerberized services? If the answer to both of these questions is "yes", then the short answer to your question is due to historical concerns, the service key for AFS is stored in it's own file and asetkey is used to bridge the gap between the Kerberos keytab and the AFS KeyFile. If the answer to the questions I have asked is "no", then the best thing you should do is read up on how Kerberos authentication works. That's not meant to be flippant; it's just that any explanation I could give you now would be rather short and incomplete. Once you understand how Kerberos works, then the purpose of the AFS principal and the KeyFile should be obvious. --Ken From jaltman@secure-endpoints.com Tue Oct 30 14:01:05 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 30 Oct 2007 09:01:05 -0400 Subject: [OpenAFS] 'afs' principal In-Reply-To: <47272834.5080001@rampaginggeek.com> References: <472722A6.7090904@kickflop.net> <47272834.5080001@rampaginggeek.com> Message-ID: <47272B11.2090103@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms010104030502060500090300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jason Edgecombe wrote: > Jeff Blaine wrote: >> Something I've never been very clear on as part of the >> conversion to Kerberos 5: The whole asetkey and afs >> principal operation. >> >> Could anyone explain what is going on there in detail >> for my (and everyone's) understanding/documentation? > Hi Jeff, > > Here is my (possibly flawed) understanding of the background: > > The afs@REALM kerberos principle is the crypto key that all AFS servers > use to talk to once another. A client authenticates to kerberos and then > runs aklog to get a ticket for the AFS service. It does this by having > the asking the KDC for the afs/CELLNAME@REALM, then afs@REALM service > principals using whichever is found first. > > The key for the afs/CELL@REALM principal or afs@REALM principal is used > by all AFS servers and resides in the Keyfile. The asetkey command takes > the kerberos keytab for the kerberos afs principal and stores it in the > Keyfile in a format that the AFS server understands. > > Someone please correct me if I'm wrong. > > Jason Jason: You got it right. The language is just a bit off. afs/cellname@REALM (or afs@REALM which using the older convention) is the Kerberos v5 service principal for the AFS cell. The key assigned to that principal must be single DES. You create the key in the KDC database and then export it to a Kerberos v5 keytab file (as you would for any Kerberos v5 authenticated service.) AFS servers do not understand the Kerberos v5 keytab format. Instead they have their own equivalent, the KeyFile. asetkey copies the an entry out of a Kerberos v5 keytab and stores it into the AFS KeyFile. The key in the AFS KeyFile is used for authentication between the AFS clients and the AFS Servers and is also used for authenticated communication between the servers themselves. Jeffrey Altman --------------ms010104030502060500090300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMzAxMzAxMDVaMCMGCSqGSIb3DQEJBDEWBBRyBeYl hGys9WEq3F2UASqZGoyrIzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAZanbjV/buHUcy71D5iPx2P+TbzhM0/sr8tuIVnRRPmJ05tJ9SD1s VuDhUQUrGHpSZvIYXtmlnH7LCfraMabktT78P3TgIAAtv/W18DbHE16q9ZREw2UeRmo2YpIj EPP7yAbRW9u4KZKfI4ua3wOMGc3ngZlsLGoirm1Jb9B5t2mgVtP8PZzM5+HM4BcFpB2RdBdS h8dvKEBTY1gR6v9/KOE2abdtUHcAwyEZmq0ZjY8g6Z8ekJsQb2ssqNh8TFqAQbzDEG5PJljx D517KOZy7KwvOuVUxTyQYWMwZplyPU1sk2eKXETIg3W1rmEHabS7ozm9eOUWuOEiQ2bdlRHa ygAAAAAAAA== --------------ms010104030502060500090300-- From jblaine@kickflop.net Tue Oct 30 14:11:20 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Tue, 30 Oct 2007 09:11:20 -0400 Subject: [OpenAFS] 'afs' principal In-Reply-To: <47272B11.2090103@secure-endpoints.com> References: <472722A6.7090904@kickflop.net> <47272834.5080001@rampaginggeek.com> <47272B11.2090103@secure-endpoints.com> Message-ID: <47272D78.3080801@kickflop.net> The exact clarity of explanation I was looking for. For some reason my ignorance of the keytab format compatibility issue was making things pretty muddled. I was sure something more special was going on. Thanks all. Jeffrey Altman wrote: > Jason Edgecombe wrote: >> Jeff Blaine wrote: >>> Something I've never been very clear on as part of the >>> conversion to Kerberos 5: The whole asetkey and afs >>> principal operation. >>> >>> Could anyone explain what is going on there in detail >>> for my (and everyone's) understanding/documentation? >> Hi Jeff, >> >> Here is my (possibly flawed) understanding of the background: >> >> The afs@REALM kerberos principle is the crypto key that all AFS servers >> use to talk to once another. A client authenticates to kerberos and then >> runs aklog to get a ticket for the AFS service. It does this by having >> the asking the KDC for the afs/CELLNAME@REALM, then afs@REALM service >> principals using whichever is found first. >> >> The key for the afs/CELL@REALM principal or afs@REALM principal is used >> by all AFS servers and resides in the Keyfile. The asetkey command takes >> the kerberos keytab for the kerberos afs principal and stores it in the >> Keyfile in a format that the AFS server understands. >> >> Someone please correct me if I'm wrong. >> >> Jason > > Jason: > > You got it right. The language is just a bit off. > > afs/cellname@REALM (or afs@REALM which using the older convention) is > the Kerberos v5 service principal for the AFS cell. The key assigned to > that principal must be single DES. You create the key in the KDC > database and then export it to a Kerberos v5 keytab file (as you would > for any Kerberos v5 authenticated service.) AFS servers do not > understand the Kerberos v5 keytab format. Instead they have their own > equivalent, the KeyFile. asetkey copies the an entry out of a Kerberos > v5 keytab and stores it into the AFS KeyFile. > > The key in the AFS KeyFile is used for authentication between the AFS > clients and the AFS Servers and is also used for authenticated > communication between the servers themselves. > > Jeffrey Altman > > From jblaine@kickflop.net Wed Oct 31 15:32:37 2007 From: jblaine@kickflop.net (Jeff Blaine) Date: Wed, 31 Oct 2007 10:32:37 -0400 Subject: [OpenAFS] Mac OS X + aklog integration Message-ID: <47289205.5070804@kickflop.net> I don't see a native way to run aklog once krb5 creds are acquired. Is that true? Any implementation tips would be great to hear. From sxw@inf.ed.ac.uk Wed Oct 31 15:42:24 2007 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Wed, 31 Oct 2007 14:42:24 +0000 Subject: [OpenAFS] Mac OS X + aklog integration In-Reply-To: <47289205.5070804@kickflop.net> References: <47289205.5070804@kickflop.net> Message-ID: <0DAC3799-F505-4D7B-9BD1-AF25A5B03359@inf.ed.ac.uk> On 31 Oct 2007, at 14:32, Jeff Blaine wrote: > I don't see a native way to run aklog once krb5 creds > are acquired. Is that true? Certainly with 10.4, you can use a loginLogout plugin to renew your AFS tokens whenever your Kerberos credentials are renewed. There are a few AFS loginLogout plugins available - although I didn't have much luck with the one I tried (when dealing with credential renewal, it seemed to try to use the credentials that had just expired to get AFS tokens). I keep meaning to look into this further, but haven't got round to it yet. Cheers, Simon. From elbarto@staff.epita.fr Wed Oct 31 15:44:31 2007 From: elbarto@staff.epita.fr (Emmanuel Vadot) Date: Wed, 31 Oct 2007 15:44:31 +0100 Subject: [OpenAFS] Change user id ? Message-ID: <472894CF.4080606@staff.epita.fr> Hello afs user, Is there a way to change the id of a user in the protection database ? For now the only way I've found is to delete then recreate the user. Thanks a lot. -- Emmanuel Vadot System & Network Administrator [root & bocal] elbarto@epitech.net 14-16 rue Voltaire 94270 Le Kremlin-Bicetre 01 44 08 01 91 06 83 14 62 92 From mdw@spam.ifs.umich.edu Wed Oct 31 16:04:16 2007 From: mdw@spam.ifs.umich.edu (Marcus Watts) Date: Wed, 31 Oct 2007 11:04:16 -0400 Subject: [OpenAFS] Change user id ? In-Reply-To: <472894CF.4080606@staff.epita.fr> References: <472894CF.4080606@staff.epita.fr> Message-ID: > Date: Wed, 31 Oct 2007 15:44:31 BST > To: openafs-info@openafs.org > From: Emmanuel Vadot > Subject: [OpenAFS] Change user id ? > > Hello afs user, > > Is there a way to change the id of a user in the protection database ? > For now the only way I've found is to delete then recreate the user. > > Thanks a lot. Yes, there is a way. Invoke PR_UpdateEntry with the PRUPDATE_ID bit set in entry->Mask, and the new id in entry->id. In recent openafs releases, call ubik_PR_UpdateEntry instead of ubik_Call. Be careful of any filesystem acl's, they won't be changed. -Marcus Watts From megacz@hcoop.net Wed Oct 31 05:33:52 2007 From: megacz@hcoop.net (Adam Megacz) Date: Tue, 30 Oct 2007 21:33:52 -0700 Subject: [OpenAFS] linux sparc64 volserver crashes (both 1.4.2 and 1.4.4) Message-ID: Hello, Using both OpenAFS 1.4.2 (debian packages) and 1.4.4 (from source) we have been unable to get "vos create" to succeed on sparc64 without volserver crashing. We're using glibc 2.3.6. An strace on volserver looks something like this: # strace -p 3583 Process 3583 attached - interrupt to quit rt_sigsuspend([] <<<<<<>>>>>> = ? ERESTARTNOHAND (To be restarted) PANIC: attached pid 3583 exited Process 3583 detached On the client side, it looks like this: Could not change quota (error -1078527744), continuing... : No such file or directory Failed to end the transaction on the volume test101 536893291 : No such file or directory Error in vos create command. : No such file or directory Any suggestions on how to troubleshoot this? Suboptimal workarounds are welcome. I believe this is the same problem which was also recently reported here with 1.4.5: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448380 Thanks! - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 From jaltman@secure-endpoints.com Wed Oct 31 16:43:14 2007 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 31 Oct 2007 11:43:14 -0400 Subject: [OpenAFS] linux sparc64 volserver crashes (both 1.4.2 and 1.4.4) In-Reply-To: References: Message-ID: <4728A292.7010300@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080007000809070803060703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Megacz wrote: > Hello, > > Using both OpenAFS 1.4.2 (debian packages) and 1.4.4 (from source) we > have been unable to get "vos create" to succeed on sparc64 without > volserver crashing. We're using glibc 2.3.6. > > An strace on volserver looks something like this: > > # strace -p 3583 > Process 3583 attached - interrupt to quit > rt_sigsuspend([] > <<<<<<>>>>>> > = ? ERESTARTNOHAND (To be restarted) > PANIC: attached pid 3583 exited > Process 3583 detached Stack trace from core? Bug reports to openafs-bugs@openafs.org --------------ms080007000809070803060703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEwMzExNTQzMTRaMCMGCSqGSIb3DQEJBDEWBBSJkLq6 8RGURT+tixbjmHWVgIC9GTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAALXbH6jPOxYth+o8UOYga13qVnRD29LU5cfsc4n2bZSSBU9RCQDI M0mSKAkhAZVUgGmeWaIIdgSJR+mKde4qedZx4McQj/tLUZFh69reC44ltrac/aZiqaFdLKo/ 2Nj5bOVkZBGDHOf4TqRg/VCgszcV8IFSAM75ahqx0gkoxy0GQxakAwdLQa3X4SfLdy/aturj dADtgIpC8mi+V/fHLNJMPGr667OUrRyVYqCVH/g5gXBXUnJkG3UmSEwoeAQfow3lgbBdkC/f F8/Af0phkif2CM92N5RcD5HL9ZmDk86QGzzCf/oopVqsJ3EWJ+a1vWEi2kOawliK6AP8cO7x bgAAAAAAAA== --------------ms080007000809070803060703-- From shadow@gmail.com Wed Oct 31 16:51:49 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 31 Oct 2007 11:51:49 -0400 Subject: [OpenAFS] Mac OS X + aklog integration In-Reply-To: <47289205.5070804@kickflop.net> References: <47289205.5070804@kickflop.net> Message-ID: ------=_Part_6583_2612776.1193845909287 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/31/07, Jeff Blaine wrote: > > I don't see a native way to run aklog once krb5 creds > are acquired. Is that true? > > Any implementation tips would be great to hear. You might ask on port-darwin@openafs.org, i think a few of those people don't read this list. Probably now that things are stable we should consider shipping whatever is needed for both login and kinit in 10.5, at least, and 10.4 also, preferably. ------=_Part_6583_2612776.1193845909287 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/31/07, Jeff Blaine <jblaine@kickflop.net> wrote:
I don't see a native way to run aklog once krb5 creds
are acquired.  Is that true?

Any implementation tips would be great to hear.

You might ask on port-darwin@openafs.org, i think a few of those people don't read this list.

Probably now that things are stable we should consider shipping whatever is needed for both login and kinit in 10.5, at least, and 10.4 also, preferably.
 


------=_Part_6583_2612776.1193845909287-- From jslife@modwest.com Wed Oct 31 18:13:22 2007 From: jslife@modwest.com (Jacob Slife) Date: Wed, 31 Oct 2007 11:13:22 -0600 Subject: [OpenAFS] Error rebuilding src rpms with linux 2.6.23 fc7 Message-ID: <4728B7B2.6000507@modwest.com> Greetings, Has anyone else encountered any problems rebuilding openafs-kernel against the new fc7 2.6.23 kernel? $> rpmbuild --rebuild --target=i686 openafs-1.4.4-fc7.3.src.rpm Installing openafs-1.4.4-fc7.3.src.rpm Building target platforms: i686 Building for target i686 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.58688 + umask 022 + cd /usr/src/redhat/BUILD + LANG=C + export LANG + unset DISPLAY + : @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ + : @@@ + : @@@ kernel version: 2.6.23.1-10.fc7 + : @@@ base kernel version:2.6.23.1-10.fc7 + : @@@ kernel modules dir: /lib/modules/2.6.23.1-10.fc7 + : @@@ kernel source dir: /lib/modules/2.6.23.1-10.fc7/build + : @@@ kernel type: up + : @@@ PAM modules dir: /lib/security + : @@@ build userspace: 0 + : @@@ build modules: 1 + : @@@ arch: i386 + : @@@ target cpu: i686 + : @@@ + : @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ + cd /usr/src/redhat/BUILD + rm -rf openafs-1.4.3 + /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/openafs-1.4.3-src.tar.bz2 + tar -xf - ... ... ... /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:266: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c: In function 'afs_alloc_inode': /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:276: error: 'afs_inode_cachep' undeclared (first use in this function) /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:276: error: (Each undeclared identifier is reported only once /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:276: error: for each function it appears in.) /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c: In function 'afs_destroy_inode': /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:287: error: 'afs_inode_cachep' undeclared (first use in this function) /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c: At top level: /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:291: error: expected declaration specifiers or '...' before 'kmem_cache_t' /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c: In function 'afs_init_inodecache': /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:309: error: 'afs_inode_cachep' undeclared (first use in this function) /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:312: warning: passing argument 5 of 'kmem_cache_create' from incompatible pointer type /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:312: error: too many arguments to function 'kmem_cache_create' /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c: In function 'afs_destroy_inodecache': /usr/src/redhat/BUILD/openafs-1.4.3/src/libafs/MODLOAD-2.6.23.1-10.fc7-SP/osi_vfsops.c:321: error: 'afs_inode_cachep' undeclared (first use in this function) -------- Jacob Slife From sxw@inf.ed.ac.uk Wed Oct 31 18:18:32 2007 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Wed, 31 Oct 2007 17:18:32 +0000 Subject: [OpenAFS] Error rebuilding src rpms with linux 2.6.23 fc7 In-Reply-To: <4728B7B2.6000507@modwest.com> References: <4728B7B2.6000507@modwest.com> Message-ID: On 31 Oct 2007, at 17:13, Jacob Slife wrote: > Has anyone else encountered any problems rebuilding openafs-kernel > against the new fc7 2.6.23 kernel? Try 1.4.5? Simon. From gtb@slac.stanford.edu Wed Oct 31 18:33:06 2007 From: gtb@slac.stanford.edu (Buhrmaster, Gary) Date: Wed, 31 Oct 2007 10:33:06 -0700 Subject: [OpenAFS] Error rebuilding src rpms with linux 2.6.23 fc7 In-Reply-To: <4728B7B2.6000507@modwest.com> References: <4728B7B2.6000507@modwest.com> Message-ID: =20 > Greetings, >=20 > Has anyone else encountered any problems rebuilding openafs-kernel=20 > against the new fc7 2.6.23 kernel? >=20 > $> rpmbuild --rebuild --target=3Di686 openafs-1.4.4-fc7.3.src.rpm Unlike some other OS's, many new Linux kernels introduce new/different interfaces. It is unlikely that an older AFS release had sufficient precognition to deal with the future definitions. AFS 1.4.5 added 2.6.23 support. I recommend you try that. The announcement can be found at: https://lists.openafs.org/pipermail/openafs-announce/2007/000214.html Gary From matt.smith@uconn.edu Wed Oct 31 18:41:25 2007 From: matt.smith@uconn.edu (Smith, Matt) Date: Wed, 31 Oct 2007 13:41:25 -0400 Subject: [OpenAFS] OpenAFS kernel module Linux/s390 Message-ID: <1193852486.7100.17.camel@d80h167.uconn.edu> --=-bOwITA4VHUYNnuirUae4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable All- Can anyone recommend an OpenAFS module version and Linux kernel version that are known to work on Linux/s390x? I am using Debian Etch on s390x, and have tried both the 2.6.18 and 2.6.22 (from etch-backports) kernels, with the OpenAFS module 1.4.2-6 package and 1.4.5pre2 from source, with no success. To avoid excessive debugging info until requested, I'll simply state that the above combos fail with references to conflicting types for 'lockIdcmp2', 'HandleFlock' and 'lockIdSet', within afs_vnop_flock.c . If it is useful, I can send whatever output is requested. I just didn't want to flood the list if it is known that it "just won't work". Thanks all, -Matt --=20 Matt Smith matt.smith@uconn.edu University Information Technology Services (UITS) University of Connecticut PGP Key ID: 0xE9C5244E --=-bOwITA4VHUYNnuirUae4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHKL5FGP63pOnFJE4RAuT0AJ0Y+bTtJaZE7yGsUycFp8h4kHnreQCgsuxU LIG0oNeetCQJ5x4EMALn3EM= =gbnX -----END PGP SIGNATURE----- --=-bOwITA4VHUYNnuirUae4-- From jslife@modwest.com Wed Oct 31 18:43:43 2007 From: jslife@modwest.com (Jacob Slife) Date: Wed, 31 Oct 2007 11:43:43 -0600 Subject: [OpenAFS] Error rebuilding src rpms with linux 2.6.23 fc7 In-Reply-To: References: <4728B7B2.6000507@modwest.com> Message-ID: <4728BECF.7090807@modwest.com> >> Greetings, >> >> Has anyone else encountered any problems rebuilding openafs-kernel >> against the new fc7 2.6.23 kernel? >> >> $> rpmbuild --rebuild --target=i686 openafs-1.4.4-fc7.3.src.rpm >> > > Unlike some other OS's, many new Linux kernels introduce > new/different interfaces. It is unlikely that an older > AFS release had sufficient precognition to deal with > the future definitions. > > AFS 1.4.5 added 2.6.23 support. I recommend you try that. > > The announcement can be found at: > https://lists.openafs.org/pipermail/openafs-announce/2007/000214.html Thanks Gary/Simon. I'll look to the 1.4.5 release. -------- Jacob Slife From shadow@gmail.com Wed Oct 31 19:07:45 2007 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 31 Oct 2007 14:07:45 -0400 Subject: [OpenAFS] OpenAFS kernel module Linux/s390 In-Reply-To: <1193852486.7100.17.camel@d80h167.uconn.edu> References: <1193852486.7100.17.camel@d80h167.uconn.edu> Message-ID: ------=_Part_7729_10324358.1193854065297 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/31/07, Smith, Matt wrote: > > All- > Can anyone recommend an OpenAFS module version and Linux kernel > version that are known to work on Linux/s390x? I am using Debian Etch > on s390x, and have tried both the 2.6.18 and 2.6.22 (from > etch-backports) kernels, with the OpenAFS module 1.4.2-6 package and > 1.4.5pre2 from source, with no success. > > To avoid excessive debugging info until requested, I'll simply state > that the above combos fail with references to conflicting types for > 'lockIdcmp2', 'HandleFlock' and 'lockIdSet', within afs_vnop_flock.c . > > If it is useful, I can send whatever output is requested. I just > didn't want to flood the list if it is known that it "just won't work". that should have been fixed in 1.4.4; it hints that configure isn't working right detecting features in your kernel. you might put config.log somewhere, as well as the log messages. you don't have to mail it. AFS or on the web is fine. ------=_Part_7729_10324358.1193854065297 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/31/07, Smith, Matt <matt.smith@uconn.edu> wrote:
All-
  Can anyone recommend an OpenAFS module version and Linux kernel
version that are known to work on Linux/s390x?  I am using Debian Etch
on s390x, and have tried both the 2.6.18 and 2.6.22 (from
etch-backports) kernels, with the OpenAFS module 1.4.2-6 package and
1.4.5pre2 from source, with no success.

  To avoid excessive debugging info until requested, I'll simply state
that the above combos fail with references to conflicting types for
'lockIdcmp2', 'HandleFlock' and 'lockIdSet', within afs_vnop_flock.c .

  If it is useful, I can send whatever output is requested.  I just
didn't want to flood the list if it is known that it "just won't work".

that should have been fixed in 1.4.4; it hints that configure isn't working right detecting features in your kernel.

 you might put config.log somewhere, as well as the log messages. you don't have to mail it. AFS or on the web is fine.
------=_Part_7729_10324358.1193854065297-- From megacz@hcoop.net Wed Oct 31 19:13:58 2007 From: megacz@hcoop.net (Adam Megacz) Date: Wed, 31 Oct 2007 11:13:58 -0700 Subject: [OpenAFS] Re: linux sparc64 volserver crashes (both 1.4.2 and 1.4.4) References: <4728A292.7010300@secure-endpoints.com> Message-ID: Jeffrey Altman writes: >> = ? ERESTARTNOHAND (To be restarted) >> PANIC: attached pid 3583 exited >> Process 3583 detached > Stack trace from core? None was created in /var/lib/openafs/cores. Do they get put somewhere else? - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 From megacz@hcoop.net Wed Oct 31 19:13:58 2007 From: megacz@hcoop.net (Adam Megacz) Date: Wed, 31 Oct 2007 11:13:58 -0700 Subject: [OpenAFS] Re: linux sparc64 volserver crashes (both 1.4.2 and 1.4.4) In-Reply-To: <4728A292.7010300@secure-endpoints.com> (Jeffrey Altman's message of "Wed, 31 Oct 2007 11:43:14 -0400") References: <4728A292.7010300@secure-endpoints.com> Message-ID: The following message is a courtesy copy of an article that has been posted to gmane.comp.file-systems.openafs.general as well. Jeffrey Altman writes: >> = ? ERESTARTNOHAND (To be restarted) >> PANIC: attached pid 3583 exited >> Process 3583 detached > Stack trace from core? None was created in /var/lib/openafs/cores. Do they get put somewhere else? - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 From megacz@hcoop.net Wed Oct 31 16:16:11 2007 From: megacz@hcoop.net (Adam Megacz) Date: Wed, 31 Oct 2007 08:16:11 -0700 Subject: [OpenAFS] linux sparc64 volserver crashes (both 1.4.2 and 1.4.4) Message-ID: Hello, Using both OpenAFS 1.4.2 (debian packages) and 1.4.4 (from source) we have been unable to get "vos create" to succeed on sparc64 without volserver crashing. We're using glibc 2.3.6. An strace on volserver looks something like this: # strace -p 3583 Process 3583 attached - interrupt to quit rt_sigsuspend([] <<<<<<>>>>>> = ? ERESTARTNOHAND (To be restarted) PANIC: attached pid 3583 exited Process 3583 detached On the client side, it looks like this: Could not change quota (error -1078527744), continuing... : No such file or directory Failed to end the transaction on the volume test101 536893291 : No such file or directory Error in vos create command. : No such file or directory Any suggestions on how to troubleshoot this? Suboptimal workarounds are welcome. I believe this is the same problem which was also recently reported here with 1.4.5: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448380 Thanks! - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380