From kaduk@mit.edu Sat Jan 6 02:22:36 2018 From: kaduk@mit.edu (Benjamin Kaduk) Date: Fri, 5 Jan 2018 20:22:36 -0600 Subject: [OpenAFS] OpenAFS 1.8.0 beta 4 available Message-ID: <20180106022235.GC25484@kduck.kaduk.org> --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The OpenAFS Guardians are happy to announce the availability of the fourth prerelease candidate of OpenAFS 1.8.0. Source files can be accessed via the web at: https://www.openafs.org/release/openafs-1.8.0pre4.html or via AFS at: UNIX: /afs/grand.central.org/software/openafs/candidate/1.8.0pre4/ UNC: \\/afs\grand.central.org\software\openafs\candidate\1.8.0pre4\ The changes since beta 3 include improved support for recent OS versions, such as Linux 4.15 and MacOS 10.13, and revised code to avoid the getcwd failures that are a perennial issue, recently prominent due to the kernel used in RHEL 7.4. This is expected to be the final beta version of 1.8.0. Please assist the guardians by deploying and testing this release and providing positive or negative feedback. Bug reports should be filed to openafs-bugs@openafs.org ; reports of successes should be sent to openafs-info@openafs.org. Benjamin Kaduk for the OpenAFS Guardians --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlpQMuYACgkQKNmm82Tr dRLZJAwdFezruxHv0LFeFLl0bu+a7oWfAEjo5y2Qou7hAekeDvQSP8Xn792wTZ7w CvwNMESpYf05T9AOVHtNZ9/e9crFdo/gKlzwKI5ZR5kC7bhW7XRJQsCZ8Blrh0t8 rAMKrOTGH4kVltiEJC6jmPNMXglaUH1DzerG4XFjPFeLTx5TLDg6gTckaq99FwU2 P2shmQIlldgesrHX/pu4WRoiuEdjoy59Hv0ScNeQF16oiE+60oEQpw0FSsm1GTuX PajSqWWaexb3XXEX0thrPtYVfsjX3HNMA237oYublwsIxDUO34f3dJ0pGP2JnFWx 11b+1XTGY6/Lx0JDx10Cf8WdJGSyxb8N7tCXTqBA5F9rZV1QYO/59EahoA9/C1gj JBYrYGb+WPjQ9v3pz+cA8eKzmeBJMePgISH4dXeVtpH+5MOUKN19Mms6MOcMd/Sz YIxeWqNyRf9POwGwfUe0ShYOMwedTEkFe+gBZ6pQNEGae70t7ExZtUDVKexEW+Wb jkqrB1taXHr+6w== =7nj4 -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From piessens@icsense.com Mon Jan 15 11:49:37 2018 From: piessens@icsense.com (Tim Piessens) Date: Mon, 15 Jan 2018 12:49:37 +0100 Subject: [OpenAFS] permission issue when trying to switch kerberos realms. Message-ID: <1D336AC0-2E45-4DCC-B38C-F35DEE1C45A1@icsense.com> --Apple-Mail=_6A89DC86-9A24-41E5-8A50-07F77B2E6F33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, can somebody shed some light on this issue ?=20 We are trying to switch between kerberos realms ( and servers ). original : X.COM new : X.BIZ cell : x.com I have created a new kerberos service principal afs/x.com@X.BIZ = in the new kerberos server. I have added the realm to the krb5.conf file.=20 On the client, I can kinit / aklog for both the user@X.COM = and user@X.BIZ =20 Both give me a token for afs-UID 1000. But when I try to access a folder with the X.COM token, = it works, with the X.BIZ token, I get a permission denied. What could be the root cause ?=20 How can I debug this ?=20 Thanks, Tim --Apple-Mail=_6A89DC86-9A24-41E5-8A50-07F77B2E6F33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

can= somebody shed some light on this issue ? 
We = are trying to switch between kerberos realms ( and servers ).
original : X.COM
new : X.BIZ

cell : x.com

I have created a new kerberos service = principal afs/x.com@X.BIZ in the new kerberos = server.
I have added the realm to the krb5.conf = file. 

On = the client, I can kinit / aklog for both the user@X.COM and user@X.BIZ 
Both give me a = token for afs-UID 1000.

But when I try to access a folder with the X.COM token, it works, with = the X.BIZ token, I get a permission denied.

What could be the root cause = ? 
How can I debug this ? 


Thanks,

Tim

= --Apple-Mail=_6A89DC86-9A24-41E5-8A50-07F77B2E6F33-- From haba@kth.se Mon Jan 15 12:02:28 2018 From: haba@kth.se (Harald Barth) Date: Mon, 15 Jan 2018 13:02:28 +0100 (CET) Subject: [OpenAFS] permission issue when trying to switch kerberos realms. In-Reply-To: <1D336AC0-2E45-4DCC-B38C-F35DEE1C45A1@icsense.com> References: <1D336AC0-2E45-4DCC-B38C-F35DEE1C45A1@icsense.com> Message-ID: <20180115.130228.572163033568812314.haba@habook.pdc.kth.se> Have the two service tickets different kvno (otherwise AFS can not tell them apart) and are they both installed on your AFS servers? I would start with a kvno of 1000 or so for the new cell which hopefully leaves enough headroom for keying the old cell if necessary. I actually don't know how high a kvno can be but up to 32767 (2^15-1) "feels" safe. Harald. From ballbery@sinenomine.net Mon Jan 15 12:08:36 2018 From: ballbery@sinenomine.net (brandon s allbery kf8nh) Date: Mon, 15 Jan 2018 07:08:36 -0500 Subject: [OpenAFS] permission issue when trying to switch kerberos realms. In-Reply-To: <1D336AC0-2E45-4DCC-B38C-F35DEE1C45A1@icsense.com> References: <1D336AC0-2E45-4DCC-B38C-F35DEE1C45A1@icsense.com> Message-ID: <67712A20-AA2A-4B1E-9C65-0A93FBF2DC8F@sinenomine.net> ------G46MXVC0YN69YC3U2QE6OMPUN9IZDY Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is that literally all you did as setup? If so, you would indeed be able to = get tokens, but the servers would not recognize their keys and would reject= the tokens=2E It sounds like the correct extra steps for your case are to make the follo= wing changes on the AFS database servers: (1) create a file /etc/openafs/server/krb=2Econf containing a single line,= with the two Kerberos realms on it separated by spaces (that is, "X=2ECOM = X=2EBIZ") (2) extract the afs cell principal in the X=2EBIZ domain to a keytab, and = then add that to /etc/openafs/server/rxkad=2Ekeytab=2E # ktutil ktutil: rkt /etc/openafs/server/rxkad=2Ekeytab ktutil: rkt /path/to/new/keytab ktutil: wkt /etc/openafs/server/rxkad=2Ekeytab Note that the new principal must have a different kvno from the old, and t= hat extracting it from the KDC will generate a new key and increment its kv= no=2E (If for some reason you are using openafs configured in legacy mode, that = may be /usr/afs/etc/krb=2Econf and/or /usr/afs/etc/KeyFile=2E If you are us= ing KeyFile, you will need to use the asetkey utility to manipulate it, not= ktutil=2E)=20 On January 15, 2018 6:49:37 AM EST, Tim Piessens = wrote: >Hi all, > >can somebody shed some light on this issue ?=20 >We are trying to switch between kerberos realms ( and servers )=2E >original : X=2ECOM >new : X=2EBIZ > >cell : x=2Ecom > >I have created a new kerberos service principal afs/x=2Ecom@X=2EBIZ > in the new kerberos server=2E >I have added the realm to the krb5=2Econf file=2E=20 > >On the client, I can kinit / aklog for both the user@X=2ECOM > and user@X=2EBIZ =20 >Both give me a token for afs-UID 1000=2E > >But when I try to access a folder with the X=2ECOM toke= n, >it works, with the X=2EBIZ token, I get a permission denied=2E > >What could be the root cause ?=20 >How can I debug this ?=20 > > >Thanks, > >Tim --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------G46MXVC0YN69YC3U2QE6OMPUN9IZDY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is that literally all you = did as setup? If so, you would indeed be able to get tokens, but the server= s would not recognize their keys and would reject the tokens=2E

It sounds like the correct extra steps for your case are to make the follo= wing changes on the AFS database servers:

(1) create a file /etc/openafs/server/krb=2Econf containing a single line,= with the two Kerberos realms on it separated by spaces (that is, "X= =2ECOM X=2EBIZ")

(2) extract the afs cell principal in the X=2EBIZ domain to a keytab, and = then add that to /etc/openafs/server/rxkad=2Ekeytab=2E

# ktutil
ktutil: rkt /etc/openafs/server/rxkad=2Ekeytab
ktutil: rkt /path/to/new/keytab
ktutil: wkt /etc/openafs/server/rxkad=2Ekeytab

Note that the new principal must have a different kvno from the old, and t= hat extracting it from the KDC will generate a new key and increment its kv= no=2E

(If for some reason you are using openafs configured in legacy mode, that = may be /usr/afs/etc/krb=2Econf and/or /usr/afs/etc/KeyFile=2E If you are us= ing KeyFile, you will need to use the asetkey utility to manipulate it, not= ktutil=2E)

On January 15, 2018 6:49:37 = AM EST, Tim Piessens <piessens@icsense=2Ecom> wrote:
Hi all,

can somebody s= hed some light on this issue ? 
We are trying to = switch between kerberos realms ( and servers )=2E
orig= inal : X=2ECOM
new : X=2EBIZ

cell : x=2Ecom

I have created a new kerberos se= rvice principal afs/x=2Ec= om@X=2EBIZ in the new kerberos server=2E
I ha= ve added the realm to the krb5=2Econf file=2E 
On the client, I can kinit / aklog for b= oth the user@X=2ECOM an= d user@X=2EBIZ 
Both give me a token for afs-UID 1000=2E

But when I try to access a folder wit= h the X=2ECOM token, it work= s, with the X=2EBIZ token, I get a permission denied=2E

What could be the root cause ? =
How can I debug this ? 

Than= ks,

Tim


--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------G46MXVC0YN69YC3U2QE6OMPUN9IZDY-- From piessens@icsense.com Mon Jan 15 13:54:05 2018 From: piessens@icsense.com (Tim Piessens) Date: Mon, 15 Jan 2018 14:54:05 +0100 Subject: [OpenAFS] permission issue when trying to switch kerberos realms. In-Reply-To: <67712A20-AA2A-4B1E-9C65-0A93FBF2DC8F@sinenomine.net> References: <1D336AC0-2E45-4DCC-B38C-F35DEE1C45A1@icsense.com> <67712A20-AA2A-4B1E-9C65-0A93FBF2DC8F@sinenomine.net> Message-ID: --Apple-Mail=_83E58355-F207-410A-997F-779CD9E8124B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks all, I was not aware of the krb.conf and kvno limitation. Now it works Dr. Ir. Tim Piessens CTO and Founder Gaston Geenslaan 14, 3001 Leuven, Belgium Tel. +32 16 589 705 | Fax. +32 16 589 720 www.icsense.com = | piessens@icsense.com "The information contained in this e-mail may be confidential." > On 15 Jan 2018, at 13:08, brandon s allbery kf8nh = wrote: >=20 > Is that literally all you did as setup? If so, you would indeed be = able to get tokens, but the servers would not recognize their keys and = would reject the tokens. >=20 > It sounds like the correct extra steps for your case are to make the = following changes on the AFS database servers: >=20 > (1) create a file /etc/openafs/server/krb.conf containing a single = line, with the two Kerberos realms on it separated by spaces (that is, = "X.COM X.BIZ") >=20 > (2) extract the afs cell principal in the X.BIZ domain to a keytab, = and then add that to /etc/openafs/server/rxkad.keytab. >=20 > # ktutil > ktutil: rkt /etc/openafs/server/rxkad.keytab > ktutil: rkt /path/to/new/keytab > ktutil: wkt /etc/openafs/server/rxkad.keytab >=20 > Note that the new principal must have a different kvno from the old, = and that extracting it from the KDC will generate a new key and = increment its kvno. >=20 > (If for some reason you are using openafs configured in legacy mode, = that may be /usr/afs/etc/krb.conf and/or /usr/afs/etc/KeyFile. If you = are using KeyFile, you will need to use the asetkey utility to = manipulate it, not ktutil.)=20 >=20 > On January 15, 2018 6:49:37 AM EST, Tim Piessens = wrote: > Hi all, >=20 > can somebody shed some light on this issue ?=20 > We are trying to switch between kerberos realms ( and servers ). > original : X.COM > new : X.BIZ >=20 > cell : x.com >=20 > I have created a new kerberos service principal afs/x.com@X.BIZ = in the new kerberos server. > I have added the realm to the krb5.conf file.=20 >=20 > On the client, I can kinit / aklog for both the user@X.COM = and user@X.BIZ =20 > Both give me a token for afs-UID 1000. >=20 > But when I try to access a folder with the X.COM = token, it works, with the X.BIZ token, I get a permission denied. >=20 > What could be the root cause ?=20 > How can I debug this ?=20 >=20 >=20 > Thanks, >=20 > Tim >=20 >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. --Apple-Mail=_83E58355-F207-410A-997F-779CD9E8124B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks all,
I was not aware of the krb.conf = and kvno limitation.
Now it works

Dr. Ir. Tim Piessens
CTO and Founder

Gaston Geenslaan 14, 3001 Leuven, Belgium
= Tel. +32 16 589 705 | Fax. +32 16 589 720
www.icsense.com | piessens@icsense.com=20=

"The information = contained in this e-mail may be confidential."


On 15 Jan 2018, at 13:08, brandon s allbery kf8nh <ballbery@sinenomine.net> wrote:

Is that literally all you did as setup? If so, you would = indeed be able to get tokens, but the servers would not recognize their = keys and would reject the tokens.

It sounds like the correct extra steps for your case are to make the = following changes on the AFS database servers:

(1) create a file /etc/openafs/server/krb.conf containing a single line, = with the two Kerberos realms on it separated by spaces (that is, "X.COM X.BIZ")

(2) extract the afs cell principal in the X.BIZ domain to a keytab, and = then add that to /etc/openafs/server/rxkad.keytab.

# ktutil
ktutil: rkt /etc/openafs/server/rxkad.keytab
ktutil: rkt /path/to/new/keytab
ktutil: wkt /etc/openafs/server/rxkad.keytab

Note that the new principal must have a different kvno from the old, and = that extracting it from the KDC will generate a new key and increment = its kvno.

(If for some reason you are using openafs configured in legacy mode, = that may be /usr/afs/etc/krb.conf and/or /usr/afs/etc/KeyFile. If you = are using KeyFile, you will need to use the asetkey utility to = manipulate it, not ktutil.)

On January 15, 2018 6:49:37 AM EST, Tim Piessens = <piessens@icsense.com> wrote:
Hi all,

can somebody = shed some light on this issue ? 
We are trying = to switch between kerberos realms ( and servers ).
original : X.COM
new : X.BIZ

cell : x.com

I have created a new kerberos service = principal afs/x.com@X.BIZ in the new kerberos = server.
I have added the realm to the krb5.conf = file. 

On = the client, I can kinit / aklog for both the user@X.COM and user@X.BIZ 
Both give me a = token for afs-UID 1000.

But when I try to access a folder with the X.COM token, it works, with = the X.BIZ token, I get a permission denied.

What could be the root cause = ? 
How can I debug this ? 


Thanks,

Tim


--
Sent from my Android device with K-9 Mail. Please excuse my = brevity.

= --Apple-Mail=_83E58355-F207-410A-997F-779CD9E8124B-- From haba@kth.se Wed Jan 17 10:18:44 2018 From: haba@kth.se (Harald Barth) Date: Wed, 17 Jan 2018 11:18:44 +0100 (CET) Subject: [OpenAFS] permission issue when trying to switch kerberos realms. In-Reply-To: <20180117100046.zogvggtad6nx3bfz@hanuman.astro.su.se> References: <1D336AC0-2E45-4DCC-B38C-F35DEE1C45A1@icsense.com> <20180115.130228.572163033568812314.haba@habook.pdc.kth.se> <20180117100046.zogvggtad6nx3bfz@hanuman.astro.su.se> Message-ID: <20180117.111844.2139575286099243254.haba@habook.pdc.kth.se> I wrote >>I actually don't know how high a kvno can be but up to 32767 (2^15-1) >>"feels" safe. That was probably WRONG as Sergio pointed out to me. Sergio wrote: > It doesn't feel all that safe to me. True, RFC 4120 specifies the kvno as > UInt32, but https://k5wiki.kerberos.org/wiki/Projects/Larger_key_versions > makes interesting reading. Version 1.14 isn't all that old; Debian 8 only > has version 1.12. > > Maybe if one requires rxkad-k5 it's OK to have kvno>255, but back in > Kerberos 4 days it definitely wasn't. The OpenAFS code base still contains > things like > if (kvno > 255) > return KAANSWERTOOLONG; > (in src/kauth/krb_udp.c) and > @t(kvno)@\is a @b(one byte) key identifier associated with the key. It > will be included in any ticket created by the AuthServer encrypted with > this key. > (in src/kauth/AuthServer.mss). One byte. Auch. So until rxkad-k5 (around the corner - just kidding) we are probably stuck with that. So if you want to devide your KVNO space into two parts, around 100 for each is what you get :-( Harald. From bhc@pitt.edu Wed Jan 17 14:39:53 2018 From: bhc@pitt.edu (Ben Carter) Date: Wed, 17 Jan 2018 09:39:53 -0500 Subject: [OpenAFS] permission issue when trying to switch kerberos realms. In-Reply-To: <20180117.111844.2139575286099243254.haba@habook.pdc.kth.se> References: <1D336AC0-2E45-4DCC-B38C-F35DEE1C45A1@icsense.com> <20180115.130228.572163033568812314.haba@habook.pdc.kth.se> <20180117100046.zogvggtad6nx3bfz@hanuman.astro.su.se> <20180117.111844.2139575286099243254.haba@habook.pdc.kth.se> Message-ID: <6bac25bd-eeb2-c2a9-931e-3534879f5a6b@pitt.edu> It's fixed. Ben On 01/17/2018 05:18 AM, Harald Barth wrote: > I wrote > >>> I actually don't know how high a kvno can be but up to 32767 (2^15-1) >>> "feels" safe. > That was probably WRONG as Sergio pointed out to me. > > Sergio wrote: >> It doesn't feel all that safe to me. True, RFC 4120 specifies the kvno as >> UInt32, but https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fk5wiki.kerberos.org%2Fwiki%2FProjects%2FLarger_key_versions&data=01%7C01%7Cbhc%40pitt.edu%7C4257f07ac19a4553cb8208d55d93d632%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=YirCxDFnp5GNko1Bg3vlybGPO5tPWbuZdb8vLKE09DM%3D&reserved=0 >> makes interesting reading. Version 1.14 isn't all that old; Debian 8 only >> has version 1.12. >> >> Maybe if one requires rxkad-k5 it's OK to have kvno>255, but back in >> Kerberos 4 days it definitely wasn't. The OpenAFS code base still contains >> things like >> if (kvno > 255) >> return KAANSWERTOOLONG; >> (in src/kauth/krb_udp.c) and >> @t(kvno)@\is a @b(one byte) key identifier associated with the key. It >> will be included in any ticket created by the AuthServer encrypted with >> this key. >> (in src/kauth/AuthServer.mss). > One byte. Auch. > > So until rxkad-k5 (around the corner - just kidding) we are probably > stuck with that. So if you want to devide your KVNO space into two > parts, around 100 for each is what you get :-( > > Harald. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openafs.org%2Fmailman%2Flistinfo%2Fopenafs-info&data=01%7C01%7Cbhc%40pitt.edu%7C4257f07ac19a4553cb8208d55d93d632%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=0hQeF%2BtVEFqNrf6SIXFQRpRowXKGX1z1NrJEfm51Fj4%3D&reserved=0 -- Ben Carter University of Pittsburgh/CSSD Network Operations Center bhc@pitt.edu 412-624-6470 From gaja.peters@math.uni-hamburg.de Wed Jan 17 15:52:39 2018 From: gaja.peters@math.uni-hamburg.de (Gaja Sophie Peters) Date: Wed, 17 Jan 2018 16:52:39 +0100 Subject: [OpenAFS] OpenAFS 1.8.0 beta 4 available In-Reply-To: <20180106022235.GC25484@kduck.kaduk.org> References: <20180106022235.GC25484@kduck.kaduk.org> Message-ID: (I tried sending this email about a week ago, but apparently unsuccessfull, so I am retrying with a different sender-address now.) Am 06.01.2018 um 03:22 schrieb Benjamin Kaduk: > The OpenAFS Guardians are happy to announce the availability of the fourth > prerelease candidate of OpenAFS 1.8.0. What better opportunity to test the new release, than when the DKMS of the old release from jessie (1.6.9-2+deb8u6) AND from jessie-backports (1.6.18.2-1~bpo8+1) fails to build on the new kernel with the "Meltdown"-fixes (which for Debian-Jessie is 3.16.0-5-amd64)... I created packages in a way similar to what I wrote in https://lists.openafs.org/pipermail/openafs-info/2016-December/041997.html only that I did it all on a Debian Jessie system, instead of Ubuntu 14.04. So far everything works fine, the DKMS-module was built successfully and the AFS-client seems completely usable. Greetings, Gaja Peters P.S. In case anybody can (or wants to) make use of these packages, I copied them to the AFS in the publicly accessible directory /afs/math.uni-hamburg.de/public/fmsv030/openafs-1.8.0~pre4-1_amd64_Debian-Jessie -- +---------- | IT-Gruppe, Systemadministration | Universität Hamburg, Fachbereich Mathematik | Bundesstr. 55 (Geomatikum) | Raum 212; Tel. 42838-5175 +---------- From kaduk@mit.edu Thu Jan 18 00:24:57 2018 From: kaduk@mit.edu (Benjamin Kaduk) Date: Wed, 17 Jan 2018 18:24:57 -0600 Subject: [OpenAFS] OpenAFS 1.8.0 beta 4 available In-Reply-To: References: <20180106022235.GC25484@kduck.kaduk.org> Message-ID: <20180118002457.GJ93961@kduck.kaduk.org> On Wed, Jan 17, 2018 at 04:52:39PM +0100, Gaja Sophie Peters wrote: > (I tried sending this email about a week ago, but apparently > unsuccessfull, so I am retrying with a different sender-address now.) > > > Am 06.01.2018 um 03:22 schrieb Benjamin Kaduk: > > > The OpenAFS Guardians are happy to announce the availability of the fourth > > prerelease candidate of OpenAFS 1.8.0. > > What better opportunity to test the new release, than when the DKMS of > the old release from jessie (1.6.9-2+deb8u6) AND from jessie-backports > (1.6.18.2-1~bpo8+1) fails to build on the new kernel with the > "Meltdown"-fixes (which for Debian-Jessie is 3.16.0-5-amd64)... Indeed. It's rather unfortunate that the process involved always makes the lead time for a fix in stable-proposed-updates take a couple weeks. (Not that my busy schedule is helping, either.) > I created packages in a way similar to what I wrote in > https://lists.openafs.org/pipermail/openafs-info/2016-December/041997.html > only that I did it all on a Debian Jessie system, instead of Ubuntu 14.04. > > So far everything works fine, the DKMS-module was built successfully and > the AFS-client seems completely usable. Glad to hear it -- thanks for the report! -Ben From andreas.ladanyi@kit.edu Fri Jan 19 08:28:08 2018 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Fri, 19 Jan 2018 09:28:08 +0100 Subject: [OpenAFS] Windows 10, OpenAFS 1.7, heimdal 7.4 kerberos enctype issue Message-ID: <6eb065eb-4b97-c6bf-7a82-37c48f927784@kit.edu> Hi, i try so setup windows 10, heimdal kerberos for windows and network idendity manager. The network idendity manager log tells me this kerberos error code -1765328370 which tells me that enctype is not supported. It seems that i get a kerberos 5 tgt at network idendity manager, but i never get an afs token. If i try to get a tgt for my principal with kinit and check it with klist i get an tgt for my user principal. aklog -d tells me -1765328370 for the afs service principal and so i dont get an afs token. allow_weak_crypto = true is set in the ProgramData/Kerberos/krb5.conf Any ideas ? cheers, Andreas From dirk.heinrichs@altum.de Fri Jan 19 15:37:31 2018 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Fri, 19 Jan 2018 16:37:31 +0100 Subject: [OpenAFS] Windows 10, OpenAFS 1.7, heimdal 7.4 kerberos enctype issue In-Reply-To: <6eb065eb-4b97-c6bf-7a82-37c48f927784@kit.edu> References: <6eb065eb-4b97-c6bf-7a82-37c48f927784@kit.edu> Message-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h9cJOC1LE8uBhQsPfyDd4WkQLzYVHKapf Content-Type: multipart/mixed; boundary="nKDLElbXMWFolsU0tcNSEQ8QmP4qTNjL6"; protected-headers="v1" From: Dirk Heinrichs To: openafs-info@openafs.org Message-ID: Subject: Re: [OpenAFS] Windows 10, OpenAFS 1.7, heimdal 7.4 kerberos enctype issue References: <6eb065eb-4b97-c6bf-7a82-37c48f927784@kit.edu> In-Reply-To: <6eb065eb-4b97-c6bf-7a82-37c48f927784@kit.edu> --nKDLElbXMWFolsU0tcNSEQ8QmP4qTNjL6 Content-Type: multipart/alternative; boundary="------------4B5FF89B66DD8A1F859E7B00" Content-Language: de-DE This is a multi-part message in MIME format. --------------4B5FF89B66DD8A1F859E7B00 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 19.01.2018 um 09:28 schrieb Andreas Ladanyi: > i try so setup windows 10, heimdal kerberos for windows and network > idendity manager. You don't need all this anymore nowadays. The Auristor installer should contain all you need. HTH... =C2=A0=C2=A0=C2=A0 Dirk --=20 Dirk Heinrichs GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 Sichere Internetkommunikation: http://www.retroshare.org Privacy Handbuch: https://www.privacy-handbuch.de --------------4B5FF89B66DD8A1F859E7B00 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Am 19.01.2018 um 09:28 schrieb Andreas= Ladanyi:

i try so setup windows 10, heimdal kerberos for windows and network idendity manager.

You don't need all this anymore nowadays. The Auristor= installer should contain all you need.

HTH...

=C2=A0=C2=A0=C2=A0 Dirk
--=20
Dirk Heinrichs <dirk.heinrichs@altum.de>
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de
--------------4B5FF89B66DD8A1F859E7B00-- --nKDLElbXMWFolsU0tcNSEQ8QmP4qTNjL6-- --h9cJOC1LE8uBhQsPfyDd4WkQLzYVHKapf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEJgWJ3LIo7zNO9tmf0p7rxfc7RqsFAlpiELsACgkQ0p7rxfc7 RqvJFhAAzWJ+8lrFjJRdlwdlEa9gy3ivnbvT0eTKnNpjQ2VZlKDiyB0Y2lrcyx2F fXMrJmb9ljKQuGusHvWRYsHwHIsx7zTwa3RgE0c1yV1i61Q0EjtCZ89lEs/I2hyY n7XGS+XLXFy+iBzsSSPBJSI6lCQ/YC4FWtlX5TrtxKD15CsDrGoxE/6LUlWU25hO 6/jcloCgcBuvWnXgPIE8jnajgpBVinI/MTvNexkAhwIZMggky9aaBRz3cqzMphhH uiaMeNRVTOqpwr9hRmHORzL+s8vy6gprooqDyKkgutQVlnPCMfo9DT8sCX+X8dY3 yD5iXWoeVgCXTngjcp7aQ0Vf6YC3nTZNlBgFIQBgP/nTypkOp2GBYbNGNwv8JOB7 ikbbdGir9cWn27gzsS6nWdtK9mTkr+5S2NL1mlakObXqkJbEbHMo39VFdVYLMPK+ w52h19zgYDQM4lyNRwQjfLt3KjKa2ky98LRGp+k1tIa301zUouYYA1lqCcXpB2a0 wlQueyEkQNbVYc8wNtWVlK/FW7bpEnNZIEYoWQ4agJ5dTnnFwDZkLJUgvJuZSacR LsFuPKczlZW4HKihI1tZ6+i0wLQGuax6E9jzgy6KQAFJCiWbYWLMaB+aZrpcy0Yd Slqw6MXxoElPWamtDetZqxwrm/mAkRUrDj1MyU/xrufUiI4SqPQ= =079r -----END PGP SIGNATURE----- --h9cJOC1LE8uBhQsPfyDd4WkQLzYVHKapf-- From andreas.ladanyi@kit.edu Mon Jan 22 09:19:40 2018 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Mon, 22 Jan 2018 10:19:40 +0100 Subject: [OpenAFS] Windows 10, OpenAFS 1.7, heimdal 7.4 kerberos enctype issue In-Reply-To: References: <6eb065eb-4b97-c6bf-7a82-37c48f927784@kit.edu> Message-ID: <1fa42b53-b99d-dc62-e8c1-10df74b97e4a@kit.edu> This is a multi-part message in MIME format. --------------31ADBA323D90539343F8A0E7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Dirk, > Am 19.01.2018 um 09:28 schrieb Andreas Ladanyi: > >> i try so setup windows 10, heimdal kerberos for windows and network >> idendity manager. > > You don't need all this anymore nowadays. The Auristor installer > should contain all > you need. I dont know why and whats the difference but after setting up this package it works. Thank you. cheers, Andreas > > HTH... > >     Dirk > -- > Dirk Heinrichs > GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015 > Sichere Internetkommunikation: http://www.retroshare.org > Privacy Handbuch: https://www.privacy-handbuch.de --------------31ADBA323D90539343F8A0E7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Dirk,

Am 19.01.2018 um 09:28 schrieb Andreas Ladanyi:

i try so setup windows 10, heimdal kerberos for windows and network idendity manager.

You don't need all this anymore nowadays. The Auristor installer should contain all you need.
I dont know why and whats the difference but after setting up this package it works.

Thank you.

cheers,
Andreas

HTH...

    Dirk
-- 
Dirk Heinrichs <dirk.heinrichs@altum.de>
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

--------------31ADBA323D90539343F8A0E7-- From botsch@cnf.cornell.edu Wed Jan 24 14:51:12 2018 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Wed, 24 Jan 2018 09:51:12 -0500 Subject: [OpenAFS] Announcing OpenAFS E&O Insurance Covering Code Contributions Message-ID: <20180124145112.GV15420@cnf.cornell.edu> All, On behalf of the OpenAFS Foundation Board of Directors, I am pleased to announce that the OpenAFS initiative including any paid or volunteer software development is now covered by Errors and Omissions insurance. This is a big step forward and now allows contributions of code without major fear of lawsuits. Obtaining insurance was a major undertaking with several false starts. We went through several different insurance companies and brokers to find insurance understanding of the nature of Free and Open Source Software. My thanks to the Drupal Association for pointing us at Durham and Bates who successfully assisted us through the application, quoting, and insurance binding process. A few major points of the insurance ("we" below being the Foundation and its volunteers/employees whilst contributing to the OpenAFS initiative): =E2=80=A2 We are not covered for "OOPSes" done knowingly or on purpose. =E2=80=A2 We are covered for bugs/security issues/data loss arising out o= f OOPSes. =E2=80=A2 We are covered for copyright infringment claims. =E2=80=A2 We are not covered for patent or trade secrets infringement cla= ims. The insurance binder and the policy are posted on the OpenAFS Foundation website: http://www.openafsfoundation.org/docs/insurance/mtk1562013-customer-binde= r.pdf http://www.openafsfoundation.org/docs/insurance/17-18-pkg-e-and-o-policy.= pdf If you have any questions, concerns, etc, please feel free to write. --=20 ******************************** David William Botsch OpenAFS Foundation Board botsch@cnf.cornell.edu ******************************** From sopko@cs.unc.edu Wed Jan 24 14:57:12 2018 From: sopko@cs.unc.edu (John Sopko) Date: Wed, 24 Jan 2018 09:57:12 -0500 Subject: [OpenAFS] afs db failover testing for lowest IP Message-ID: I need to upgrade our afs db servers. It has been sometime so I setup a test cell with 3 servers to see how things react when the lowest IP server is down. When the lowest IP db server is down udebug shows the second lowest IP becomes the sync site. But, I cannot do certain commands that time out because they are trying to use the lowest IP address that id down. For example I cannot do "pts listentries -users" "vos listvldb". The file services seem to be ok. I use "strace pts listentires -users" which shows the client keeps trying the down machines IP until it finally times out. Can anyone shed any light on what is going on. Thanks. -- John W. Sopko Jr. University of North Carolina Computer Science Dept CB 3175 Chapel Hill, NC 27599-3175 Fred Brooks Building; Room 140 Computer Services Systems Specialist email: sopko AT cs.unc.edu phone: 919-590-6144 From sopko@cs.unc.edu Wed Jan 24 16:17:37 2018 From: sopko@cs.unc.edu (John Sopko) Date: Wed, 24 Jan 2018 11:17:37 -0500 Subject: [OpenAFS] Re: afs db failover testing for lowest IP In-Reply-To: References: Message-ID: I did not have the secondary db machines in /usr/vice/etc/CellServDB. All is good :) On Wed, Jan 24, 2018 at 9:57 AM, John Sopko wrote: > I need to upgrade our afs db servers. It has been sometime so I setup > a test cell with 3 servers to see how things react when the lowest IP > server is down. > > When the lowest IP db server is down udebug shows the second lowest IP > becomes the sync site. But, I cannot do certain commands that time out > because they are trying to use the lowest IP address that id down. For > example I cannot do "pts listentries -users" "vos listvldb". The file > services seem to be ok. > > I use "strace pts listentires -users" which shows the client keeps > trying the down machines IP until it finally times out. Can anyone > shed any light on what is going on. Thanks. > > > -- > John W. Sopko Jr. > University of North Carolina > Computer Science Dept CB 3175 > Chapel Hill, NC 27599-3175 > > Fred Brooks Building; Room 140 > Computer Services Systems Specialist > email: sopko AT cs.unc.edu > phone: 919-590-6144 -- John W. Sopko Jr. University of North Carolina Computer Science Dept CB 3175 Chapel Hill, NC 27599-3175 Fred Brooks Building; Room 140 Computer Services Systems Specialist email: sopko AT cs.unc.edu phone: 919-590-6144 From xmgu@royole.com Wed Jan 24 19:31:51 2018 From: xmgu@royole.com (Ximeng Guan) Date: Wed, 24 Jan 2018 19:31:51 +0000 Subject: [OpenAFS] Is member of a machine group honored as system:authuser? Message-ID: <6d5952d7576942e4a8c521aa403861de@royole.com> SGVsbG8sDQoNCkkgYW0gdHJ5aW5nIHRvIG1ha2Ugc29tZSBlZmZlY3RpdmUgdXNlIG9mIG1hY2hp bmUgZ3JvdXBzIGluIEFGUyB0byBhY2NvbW1vZGF0ZSBjZXJ0YWluIHJlcXVpcmVtZW50IG9mIGxp Y2Vuc2VkIHNvZnR3YXJlLiBJIHJlYWQgYWJvdXQgdGhlIGZlYXR1cmUsIGFuZCBub3RpY2VkIHRo YXQgaW4gdGhlIDE5OTggZWRpdGlvbiBvZiB0aGUgYm9vayAiTWFuYWdpbmcgQUZTLCBUaGUgQW5k cmV3IEZpbGUgU3lzdGVtIiBieSBSaWNoYXJkIENhbXBiZWxsLCB0aGUgZm9sbG93aW5nIHRleHQg YXBwZWFyZWQgaW4gQ2hhcHRlciA3IHAuMjMwOg0KDQoiLi4uDQpUaGVyZSBpcyBvbmUgZmluYWwg cXVpcmsgdG8gdGhlIGltcGxlbWVudGF0aW9uOiBpdCdzIGNvbW1vbiBmb3Igc2V2ZXJhbCB0b3At bGV2ZWwgZGlyZWN0b3JpZXMgb2YgdGhlIEFGUyBuYW1lc3BhY2UgdG8gYmUgcGVybWl0dGVkIG9u bHkgdG8gc3lzdGVtOmF1dGh1c2VyLCB0aGF0IGlzLCBhbnkgdXNlciBjYW4gYWNjZXNzIHRoZSBy ZXN0IG9mIHRoZSBuYW1lc3BhY2UsIGJ1dCBvbmx5IGlmIHRoZSB1c2VyIGhhcyBiZWVuIGF1dGhl bnRpY2F0ZWQgYXMgYSB1c2VyLCBhbnkgdXNlciwgb2YgdGhlIGN1cnJlbnQgY2VsbC4gTWFjaGlu ZSBncm91cHMgYXJlIGludGVuZGVkIHRvIGJlIHVzZWZ1bCBmb3IgYW55IHBlcnNvbiBsb2dnZWQg aW4gdG8gYSB3b3Jrc3RhdGlvbiBzbyB0aGF0IHNvZnR3YXJlIGxpY2Vuc2VzIGNhbiBiZSBob25l c3RseSBmb2xsb3dlZC4gVGhlcmVmb3JlLCB3aGVuIGFuIHVuYXV0aGVudGljYXRlZCB1c2VyIGlz IHVzaW5nIGEgbWFjaGluZSB0aGF0IGlzIGEgbWVtYmVyIG9mIGEgZ3JvdXAgZW50cnkgb24gYW4g QUNMLCB0aGUgdXNlcidzIGltcGxpY2l0IGNyZWRlbnRpYWwgaXMgZWxldmF0ZWQgdG8gc3lzdGVt OmF1dGh1c2VyLCBidXQgb25seSBpZiB0aGUgbWFjaGluZSBlbnRyeSBpbiB0aGUgZ3JvdXAgaXMg YW4gZXhhY3QgbWF0Y2gsIG5vdCBhIHdpbGRjYXJkLg0KDQpUaGlzIHJ1bGUgcGVybWl0cyBhbnkg dXNlciBvZiBhIGdpdmVuIGRlc2t0b3AgdG8gZWZmZWN0aXZlbHkgaGF2ZSBzeXN0ZW06YXV0aHVz ZXIgY3JlZGVudGlhbHMgZm9yIGEgZGlyZWN0b3J5LiBBcyBsb25nIGFzIHRoYXQgZGlyZWN0b3J5 IGhhcyBhbiBBQ0wgdGhhdCBpbmNsdWRlcyB0aGUgc3BlY2lmaWMgbWFjaGluZSdzIElQIGFkZHJl c3MgYXMgYSBtZW1iZXIgb2YgYSBncm91cCBlbnRyeSwgYW55IHVzZXIgb2YgdGhlIGRlc2t0b3As IGFuZCBvbmx5IHRoYXQgZGVza3RvcCwgd291bGQgaGF2ZSBhY2Nlc3MgdG8gdGhlIGRpcmVjdG9y eS4gDQouLi4NCiINCg0KVGhhdCBpcyBleGFjdGx5IHdoYXQgd2UgaGF2ZSBpbiB0aGUgdG9wLWxl dmVsIGRpcmVjdG9yaWVzIGluIG91ciBjZWxsOiBXZSBoYXZlICJzeXN0ZW06YXV0aHVzZXIgcmwi IG9uIHRoZSBBQ0wgb2Ygcm9vdC5jZWxsLiANCg0KQWNjZXNzIGxpc3QgZm9yIC4gaXMNCk5vcm1h bCByaWdodHM6DQogIHN5c3RlbTphZG1pbmlzdHJhdG9ycyBybGlkd2thDQogIHN5c3RlbTphdXRo dXNlciBybA0KDQpUaGVuIHdoZW4gSSBjcmVhdGUgYSBtYWNoaW5lLWJhc2VkIHB0cyBlbnRyeSAx MC4xMi44LjMxLCBhZGQgaXQgdG8gYSBuZXcgZ3JvdXAgbmFtZWQgbWFjaGluZWdycCwgYW5kIHdh aXQgZm9yID4yIGhvdXJzIHRvIGxldCBpdCBiZSBlZmZlY3RpdmUgKGFjY29yZGluZyB0byBkYWZp bGVzZXJ2ZXIncyBtYW4gcGFnZSkNCg0KJCBwdHMgbWVtYmVyIG1hY2hpbmVncnANCk1lbWJlcnMg b2YgbWFjaGluZWdycCAoaWQ6IC0yNTApIGFyZToNCiAgMTAuMTIuOC4zMQ0KDQpJIHdvdWxkIGV4 cGVjdCB0aGF0IGEgbG9jYWwgdXNlciBvbiAxMC4xMi44LjMxLCBldmVuIHdpdGhvdXQgYW4gQUZT IHRva2VuLCB3b3VsZCBiZSBhYmxlIHRvICJjZCIgaW50byB0aGUgdG9wIGRpcmVjdG9yeSBvZiB0 aGUgY2VsbC4gQnV0IGluIHJlYWxpdHkgdGhhdCBkb2VzIG5vdCBoYXBwZW4uIEFuIHVuYXV0aGVu dGljYXRlZCB1c2VyIGlzIGRlbmllZCBvZiBhY2Nlc3MuIA0KDQpXaGVuIEkgZXhwbGljaXRseSBw dXQgIm1hY2hpbmVncnAgcmwiIG9uIHRoZSBBQ0wgb2YgdGhlIGNlbGwncyB0b3AgZGlyZWN0b3J5 IChyb290LmNlbGwpLCBhbiB1bmF1dGhlbnRpY2F0ZWQgdXNlciBpcyBpbmRlZWQgYWJsZSB0byBh Y2Nlc3MgdGhlIEFGUyBzcGFjZS4gDQoNClRoaXMgaXMgbm90IHF1aXRlIGNvbnZlbmllbnQsIGJl Y2F1c2UgdG8gYWxsb3cgdGhlIHVzZXIgb2YgdGhhdCBzcGVjaWZpYyBtYWNoaW5lIHRvIGxhdW5j aCBhIGxpY2Vuc2Ugc29mdHdhcmUgaW5zdGFsbGVkIGluIGEgY2VydGFpbiAoZGVlcCkgZGlyZWN0 b3J5IHVuZGVyIEFGUywgZm9yIGV4YW1wbGUgL2Fmcy9jZWxsbmFtZS90b29scy92ZW5kb3JzL2Fi Yy9zb2Z0d2FyZXh4L2Jpbiwgd2Ugd291bGQgaGF2ZSB0byBleHBsaWNpdGx5IHBsYWNlICJtYWNo aW5lZ3JwIGwiIG9uIHRoZSBBQ0wgb2YgdGhlIHBhcmVudCBkaXJlY3RvcmllcyBvZiAuL2JpbiBm cm9tIC9zb2Z0d2FyZXh4IGFsbCB0aGUgd2F5IHVwIHRvIC9jZWxsbmFtZS4gDQoNClRoZW4gaWYg d2UgaGF2ZSBhbm90aGVyIHNvZnR3YXJlIGFuZCBhbm90aGVyIG1hY2hpbmUgZ3JvdXAsIHdlIHdp bGwgaGF2ZSB0byBkbyB0aGUgc2FtZSBhZ2FpbiwgYW5kIHRoZSBBQ0wgb2Ygb3VyIHJvb3QuY2Vs bCBkaXJlY3Rvcnkgd2lsbCBzb29uIGJlIHBvcHVsYXRlZCB3aXRoIG1hY2hpbmUgZ3JvdXAgZW50 cmllcy4gVGhhdCBkb2VzIG5vdCBzZWVtIHRvIGJlIGFuIGVsZWdhbnQgc29sdXRpb24uIA0KDQpE aWQgSSBtaXNzIGFueXRoaW5nIGhlcmU/IA0KDQpUaGFua3MuDQoNCkJlc3QgcmVnYXJkcywNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClhpbWVuZyAoU2ltb24pIEd1 YW4sIFBoLkQuDQpBc3NvY2lhdGUgUHJpbmNpcGFsIEVuZ2luZWVyDQpSb3lvbGUgQ29ycG9yYXRp b24NCjQ4MDI1IEZyZW1vbnQgQmx2ZCwgRnJlbW9udCwgQ0EgOTQ1MzgNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCg0K From stephen@email.unc.edu Wed Jan 24 22:11:26 2018 From: stephen@email.unc.edu (Stephen Joyce) Date: Wed, 24 Jan 2018 17:11:26 -0500 (EST) Subject: [OpenAFS] Re: Re: afs db failover testing for lowest IP In-Reply-To: References: Message-ID: Hey, John. Let me know if you have more problems, or just need to bounce any ideas around. I went through something similar last summer, but I actually changed IP addresses (moved to a different VLAN). I decided to bite the bullet and virtualize my DB servers at the same time. You may want to consider the same. It has the potential to make some future tasks much simpler (esp. disaster recovery). I think I ended up having 3 short downtimes (announced 1 hour; finished in 15 mins each time) scheduled during semester breaks. For safety, I've currently got all 3 DB servers are on separate dedicated, low-power hypervisors in the same cluster (Dell R410s), so I'm not really eliminating physical boxes per-se, but it gives me flexibility to snap the VMs, reboot *fast*, live migrate the VMs between HVs for patching, hardware upgrades, etc... Stephen On Wed, 24 Jan 2018, John Sopko wrote: > I did not have the secondary db machines in /usr/vice/etc/CellServDB. > All is good :) > > On Wed, Jan 24, 2018 at 9:57 AM, John Sopko wrote: >> I need to upgrade our afs db servers. It has been sometime so I setup >> a test cell with 3 servers to see how things react when the lowest IP >> server is down. >> >> When the lowest IP db server is down udebug shows the second lowest IP >> becomes the sync site. But, I cannot do certain commands that time out >> because they are trying to use the lowest IP address that id down. For >> example I cannot do "pts listentries -users" "vos listvldb". The file >> services seem to be ok. >> >> I use "strace pts listentires -users" which shows the client keeps >> trying the down machines IP until it finally times out. Can anyone >> shed any light on what is going on. Thanks. >> >> >> -- >> John W. Sopko Jr. >> University of North Carolina >> Computer Science Dept CB 3175 >> Chapel Hill, NC 27599-3175 >> >> Fred Brooks Building; Room 140 >> Computer Services Systems Specialist >> email: sopko AT cs.unc.edu >> phone: 919-590-6144 > > > > -- > John W. Sopko Jr. > University of North Carolina > Computer Science Dept CB 3175 > Chapel Hill, NC 27599-3175 > > Fred Brooks Building; Room 140 > Computer Services Systems Specialist > email: sopko AT cs.unc.edu > phone: 919-590-6144 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Stephen Joyce Linux Systems Specialist Office of Arts & Sciences Information Services University of North Carolina at Chapel Hill From stephen@email.unc.edu Wed Jan 24 22:38:39 2018 From: stephen@email.unc.edu (Stephen Joyce) Date: Wed, 24 Jan 2018 17:38:39 -0500 (EST) Subject: [OpenAFS] Re: Re: afs db failover testing for lowest IP In-Reply-To: References: Message-ID: That was intended to be addressed only to John. Mea culpa. On Wed, 24 Jan 2018, Stephen Joyce wrote: > Hey, John. > > Let me know if you have more problems, or just need to bounce any ideas > around. > > I went through something similar last summer, but I actually changed IP > addresses (moved to a different VLAN). I decided to bite the bullet and > virtualize my DB servers at the same time. You may want to consider the > same. It has the potential to make some future tasks much simpler (esp. > disaster recovery). > > I think I ended up having 3 short downtimes (announced 1 hour; finished in > 15 mins each time) scheduled during semester breaks. > > For safety, I've currently got all 3 DB servers are on separate dedicated, > low-power hypervisors in the same cluster (Dell R410s), so I'm not really > eliminating physical boxes per-se, but it gives me flexibility to snap the > VMs, reboot *fast*, live migrate the VMs between HVs for patching, hardware > upgrades, etc... > > Stephen > > On Wed, 24 Jan 2018, John Sopko wrote: > >> I did not have the secondary db machines in /usr/vice/etc/CellServDB. >> All is good :) >> >> On Wed, Jan 24, 2018 at 9:57 AM, John Sopko wrote: >>> I need to upgrade our afs db servers. It has been sometime so I setup >>> a test cell with 3 servers to see how things react when the lowest IP >>> server is down. >>> >>> When the lowest IP db server is down udebug shows the second lowest IP >>> becomes the sync site. But, I cannot do certain commands that time out >>> because they are trying to use the lowest IP address that id down. For >>> example I cannot do "pts listentries -users" "vos listvldb". The file >>> services seem to be ok. >>> >>> I use "strace pts listentires -users" which shows the client keeps >>> trying the down machines IP until it finally times out. Can anyone >>> shed any light on what is going on. Thanks. >>> >>> >>> -- >>> John W. Sopko Jr. >>> University of North Carolina >>> Computer Science Dept CB 3175 >>> Chapel Hill, NC 27599-3175 >>> >>> Fred Brooks Building; Room 140 >>> Computer Services Systems Specialist >>> email: sopko AT cs.unc.edu >>> phone: 919-590-6144 >> >> >> >> -- >> John W. Sopko Jr. >> University of North Carolina >> Computer Science Dept CB 3175 >> Chapel Hill, NC 27599-3175 >> >> Fred Brooks Building; Room 140 >> Computer Services Systems Specialist >> email: sopko AT cs.unc.edu >> phone: 919-590-6144 >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > -- > Stephen Joyce > Linux Systems Specialist > Office of Arts & Sciences Information Services > University of North Carolina at Chapel Hill > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > Sincerely, Stephen -- Stephen Joyce Linux Systems Specialist Office of Arts & Sciences Information Services University of North Carolina at Chapel Hill Need computing support within the College of Arts and Sciences? For Windows or MacOS assistance, please email oasisremedy@unc.edu. For Linux assistance, please email linux@unc.edu. From sopko@cs.unc.edu Wed Jan 24 23:43:26 2018 From: sopko@cs.unc.edu (John Sopko) Date: Wed, 24 Jan 2018 18:43:26 -0500 Subject: [OpenAFS] Re: Re: afs db failover testing for lowest IP Message-ID: Were all friends, good to let the group know some of our issues! In my case I built openafs 1.6.22.1 For Redhat 6.9 since there are no binaries. When I updated it nuked the /usr/vice/etc/CellServDB.local on my working cell so the clients did not know about about the secondary servers anymore. We use dns afsdb records for our productions cell so this is not an issue, just my test cell. I am doing testing to move to Redhat 7.4. I will ping you about all this, thanks for the info. On Wed, Jan 24, 2018 at 5:38 PM, Stephen Joyce wrote: > That was intended to be addressed only to John. Mea culpa. > > > On Wed, 24 Jan 2018, Stephen Joyce wrote: > >> Hey, John. >> >> Let me know if you have more problems, or just need to bounce any ideas >> around. >> >> I went through something similar last summer, but I actually changed IP >> addresses (moved to a different VLAN). I decided to bite the bullet and >> virtualize my DB servers at the same time. You may want to consider the >> same. It has the potential to make some future tasks much simpler (esp. >> disaster recovery). >> >> I think I ended up having 3 short downtimes (announced 1 hour; finished in >> 15 mins each time) scheduled during semester breaks. >> >> For safety, I've currently got all 3 DB servers are on separate dedicated, >> low-power hypervisors in the same cluster (Dell R410s), so I'm not really >> eliminating physical boxes per-se, but it gives me flexibility to snap the >> VMs, reboot *fast*, live migrate the VMs between HVs for patching, >> hardware >> upgrades, etc... >> >> Stephen >> >> On Wed, 24 Jan 2018, John Sopko wrote: >> >>> I did not have the secondary db machines in /usr/vice/etc/CellServDB. >>> All is good :) >>> >>> On Wed, Jan 24, 2018 at 9:57 AM, John Sopko wrote: >>>> >>>> I need to upgrade our afs db servers. It has been sometime so I setup >>>> a test cell with 3 servers to see how things react when the lowest IP >>>> server is down. >>>> >>>> When the lowest IP db server is down udebug shows the second lowest IP >>>> becomes the sync site. But, I cannot do certain commands that time out >>>> because they are trying to use the lowest IP address that id down. For >>>> example I cannot do "pts listentries -users" "vos listvldb". The file >>>> services seem to be ok. >>>> >>>> I use "strace pts listentires -users" which shows the client keeps >>>> trying the down machines IP until it finally times out. Can anyone >>>> shed any light on what is going on. Thanks. >>>> >>>> >>>> -- >>>> John W. Sopko Jr. >>>> University of North Carolina >>>> Computer Science Dept CB 3175 >>>> Chapel Hill, NC 27599-3175 >>>> >>>> Fred Brooks Building; Room 140 >>>> Computer Services Systems Specialist >>>> email: sopko AT cs.unc.edu >>>> phone: 919-590-6144 >>> >>> >>> >>> >>> -- >>> John W. Sopko Jr. >>> University of North Carolina >>> Computer Science Dept CB 3175 >>> Chapel Hill, NC 27599-3175 >>> >>> Fred Brooks Building; Room 140 >>> Computer Services Systems Specialist >>> email: sopko AT cs.unc.edu >>> phone: 919-590-6144 >>> _______________________________________________ >>> OpenAFS-info mailing list >>> OpenAFS-info@openafs.org >>> https://lists.openafs.org/mailman/listinfo/openafs-info >>> >> >> -- >> Stephen Joyce >> Linux Systems Specialist >> Office of Arts & Sciences Information Services >> University of North Carolina at Chapel Hill >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > Sincerely, > Stephen > -- > Stephen Joyce > Linux Systems Specialist > Office of Arts & Sciences Information Services > University of North Carolina at Chapel Hill > > Need computing support within the College of Arts and Sciences? > For Windows or MacOS assistance, please email oasisremedy@unc.edu. > For Linux assistance, please email linux@unc.edu. > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- John W. Sopko Jr. University of North Carolina Computer Science Dept CB 3175 Chapel Hill, NC 27599-3175 Fred Brooks Building; Room 140 Computer Services Systems Specialist email: sopko AT cs.unc.edu phone: 919-590-6144 From drosih@rpi.edu Thu Jan 25 03:11:37 2018 From: drosih@rpi.edu (Garance A Drosehn) Date: Wed, 24 Jan 2018 22:11:37 -0500 Subject: [OpenAFS] Is member of a machine group honored as system:authuser? In-Reply-To: <6d5952d7576942e4a8c521aa403861de@royole.com> References: <6d5952d7576942e4a8c521aa403861de@royole.com> Message-ID: On 24 Jan 2018, at 14:31, Ximeng Guan wrote: > I would expect that a local user on 10.12.8.31, even without an AFS > token, would be able to "cd" into the top directory of the cell. But > in reality that does not happen. An unauthenticated user is denied of > access. > > When I explicitly put "machinegrp rl" on the ACL of the cell's top > directory (root.cell), an unauthenticated user is indeed able to > access the AFS space. > > This is not quite convenient, because to allow the user of that > specific machine to launch a license software installed in a certain > (deep) directory under AFS, for example > /afs/cellname/tools/vendors/abc/softwarexx/bin, we would have to > explicitly place "machinegrp l" on the ACL of the parent directories > of ./bin from /softwarexx all the way up to /cellname. > > Then if we have another software and another machine group, we will > have to do the same again, and the ACL of our root.cell directory will > soon be populated with machine group entries. That does not seem to be > an elegant solution. Well, one thing you could do is create one PTS group, add the individual machine-groups to that common PTS group, and then use the the common PTS group for permitting directories. And then when you get to a directory which has to be permitted to just one of those machines (and not to any other machine groups), you'd use the individual machine-group instead of the common one. I use IP-based permissions for a few things. In at least one case, it looks like I created a single group, and then kept adding the IP addresses as new entries in that one PTS group. You might also have to logout and log back in again. I have a vague memory that PTS groups are only evaluated at login time. I'm not sure that works with machine-groups. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From kaduk@mit.edu Thu Jan 25 04:14:24 2018 From: kaduk@mit.edu (Benjamin Kaduk) Date: Wed, 24 Jan 2018 22:14:24 -0600 Subject: [OpenAFS] Is member of a machine group honored as system:authuser? In-Reply-To: <6d5952d7576942e4a8c521aa403861de@royole.com> References: <6d5952d7576942e4a8c521aa403861de@royole.com> Message-ID: <20180125041423.GN3284@kduck.kaduk.org> On Wed, Jan 24, 2018 at 07:31:51PM +0000, Ximeng Guan wrote: [snip] > Did I miss anything here? I don't think so. It's probably best to think of system:authuser as a shorthand for "all entities that can authenticate to the protection server", users and keytab-based credentials. The machine/IP prdb entries are in an intermediate space, in which they can appear on access control lists but nothing can actually authenticate directly as those pts entries. It seems like a weird design choice now, but probably made sense a the time. pts_createuser(1) has some information about the actual functionality. Garance's suggestion of (essentially) adding an additional layer of abstraction seems to be the best practice for this area. -Ben From jaltman@auristor.com Thu Jan 25 15:06:39 2018 From: jaltman@auristor.com (Jeffrey Altman) Date: Thu, 25 Jan 2018 10:06:39 -0500 Subject: [OpenAFS] Is member of a machine group honored as system:authuser? In-Reply-To: <6d5952d7576942e4a8c521aa403861de@royole.com> References: <6d5952d7576942e4a8c521aa403861de@royole.com> Message-ID: <42317181-c328-787f-f7b2-7be7cfa34fb1@auristor.com> This is a cryptographically signed message in MIME format. --------------ms080800090301030402050401 Content-Type: multipart/mixed; boundary="------------96E3083A6B21B18F47C4F30B" Content-Language: en-US This is a multi-part message in MIME format. --------------96E3083A6B21B18F47C4F30B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/24/2018 2:31 PM, Ximeng Guan wrote: > Hello, >=20 > I am trying to make some effective use of machine groups in AFS to acco= mmodate certain requirement of licensed software. I read about the featur= e, and noticed that in the 1998 edition of the book "Managing AFS, The An= drew File System" by Richard Campbell, the following text appeared in Cha= pter 7 p.230: >=20 > "... > There is one final quirk to the implementation: it's common for several= top-level directories of the AFS namespace to be permitted only to syste= m:authuser, that is, any user can access the rest of the namespace, but o= nly if the user has been authenticated as a user, any user, of the curren= t cell. Machine groups are intended to be useful for any person logged in= to a workstation so that software licenses can be honestly followed. The= refore, when an unauthenticated user is using a machine that is a member = of a group entry on an ACL, the user's implicit credential is elevated to= system:authuser, but only if the machine entry in the group is an exact = match, not a wildcard. >=20 > This rule permits any user of a given desktop to effectively have syste= m:authuser credentials for a directory. As long as that directory has an = ACL that includes the specific machine's IP address as a member of a grou= p entry, any user of the desktop, and only that desktop, would have acces= s to the directory.=20 > ... > " This text was true prior to IBM AFS 3.2 but has not been true for any release since IBM AFS 3.3. As of AFS 3.3 the Current Protection Set for a host includes neither system:anyuser nor system:authuser. In other words, hosts are not users. > That is exactly what we have in the top-level directories in our cell: = We have "system:authuser rl" on the ACL of root.cell.=20 >=20 > Access list for . is > Normal rights: > system:administrators rlidwka > system:authuser rl >=20 > Then when I create a machine-based pts entry 10.12.8.31, add it to a ne= w group named machinegrp, and wait for >2 hours to let it be effective (a= ccording to dafileserver's man page) >=20 > $ pts member machinegrp > Members of machinegrp (id: -250) are: > 10.12.8.31 >=20 > I would expect that a local user on 10.12.8.31, even without an AFS tok= en, would be able to "cd" into the top directory of the cell. But in real= ity that does not happen. An unauthenticated user is denied of access.=20 This is working as designed because the ACL does not include the host identity. >=20 > When I explicitly put "machinegrp rl" on the ACL of the cell's top dire= ctory (root.cell), an unauthenticated user is indeed able to access the A= FS space.=20 >=20 > This is not quite convenient, because to allow the user of that specifi= c machine to launch a license software installed in a certain (deep) dire= ctory under AFS, for example /afs/cellname/tools/vendors/abc/softwarexx/b= in, we would have to explicitly place "machinegrp l" on the ACL of the pa= rent directories of ./bin from /softwarexx all the way up to /cellname.=20 >=20 > Then if we have another software and another machine group, we will hav= e to do the same again, and the ACL of our root.cell directory will soon = be populated with machine group entries. That does not seem to be an eleg= ant solution.=20 >=20 > Did I miss anything here?=20 Perhaps. The problem you are attempting to solve is that there exist directories and files that must be accessible only from a particular subset of trusted machines. This data is only supposed to be visible to users of those machines and no one else. What you are possibly missing is that IP ACLs are not a form of authentication and they cannot be used to provide any integrity protection or wire privacy. Any data that is accessed by the host without a user's AFS token is going to be transmitted in the clear. In addition, IP addresses can be spoofed. This use case is one that AuriStorFS was explicitly designed to address. AuriStorFS client hosts can be keyed using Kerberos v5 principals. AuriStor's RX security class supports combined identity authentication providing the file server both the identity of the user and the identity of the host. Finally, the AuriStorFS Access Control language permits different access permissions to be granted to each of the following combinations: authenticated user on unauthenticated host authenticated user on authenticated host anonymous user on authenticated host anonymous user on anonymous host The anonymous user on authenticated host communications with the file server are authenticated using the host principal and all data is both integrity protected and encrypted for wire privacy. Jeffrey Altman AuriStor, Inc. --------------96E3083A6B21B18F47C4F30B Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------96E3083A6B21B18F47C4F30B-- --------------ms080800090301030402050401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIIwggXpMIIE0aADAgECAhBAAV7gPRitcrlGsJTzkwjvMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE3MTAwMzAzMTczM1oXDTE4MTEwMzAzMTczM1owgYUxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xLzAtBgoJkiaJk/IsZAEBEx9BMDE0MjdFMDAwMDAxNUVFMDNEMTg3QTAw MDA0QUE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqJC89ZA1DSS7t/Ug8Dd BQv5nBDumInWtFvHwVCORitVCvlkX4SfqKpERATq0eHOSc0zEz1PUjhAT8lgbNj8Bs92pL9t DW/VHHpq11w06rCEmZJNxgErAIvMpRuAhGrzvBpQBLj8nDArHWw+5nRn/KnK7ZO81LEEj4TG w0PEKGSa0aFA+JdRTJ6BZSDP2o/8AHx+Bw4JgW8VppAe4IuY/F+JoYtyQDL+fm1YMnFMtf1A 6IvlGXD7gMksPRbVIfD+QpHZbQvNXZAVVDaCWZuWQq46Vl4lSlkmW9yMlGddvFGl2zSMK7ny f0kbWJLw9lZxXDegY0/ciJPACPsyBwuyLwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgWg MIGEBggrBgEFBQcBAQR4MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3Au aWRlbnRydXN0LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0 LmNvbS9jZXJ0cy90cnVzdGlkY2FhMTIucDdjMB8GA1UdIwQYMBaAFKRz2u9pNYp1zKAZewgy +GuJ5ELsMAkGA1UdEwQCMAAwggEsBgNVHSAEggEjMIIBHzCCARsGC2CGSAGG+S8ABgsBMIIB CjBKBggrBgEFBQcCARY+aHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0 ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwgbsGCCsGAQUFBwICMIGuGoGrVGhpcyBUcnVzdElE IENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggCklkZW5U cnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2Vj dXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEUG A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL3Ry dXN0aWRjYWExMi5jcmwwHwYDVR0RBBgwFoEUamFsdG1hbkBhdXJpc3Rvci5jb20wHQYDVR0O BBYEFNefZrPaqPUvaS6V6kAmHDwFhoDiMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDANBgkqhkiG9w0BAQsFAAOCAQEAKlssrfOJ5+WwHyhFSeSsioN0qpg2QDX/uvodF38JbquO 1U0my0j3Cc/bwk48++bjzp0Fvk/Kkcmss5/6zzJMjr9rf12QCQfKkbO9nMm8Bg6IP3pYgk0W /F1h3ZQF3OgBn3zZoOd3f1a6dF6z12MqKA/2g5GKrQFxkdzTGrNw6ISE9uY8ysvc3i2N2kas HNi5Etk7StZ1jvFX5sQMIeNdlF+z+BU/AyT7NoBS4gCH+ggF+DG7fAYywvy42Lfu8p6kopKT 5JZpYce1cNjnOaDhzhgeR+oXxoDbekF27JinXHQSKjBxhujcZu5leAkpctFpZxnIKZJZUBiu 31Nm7xYaijCCBpEwggR5oAMCAQICEQD53lZ/yU0Md3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVz dCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAyMTgyMjI1MTlaFw0yMzAyMTgyMjI1MTla MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg Q0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQl a3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZoCx3wef1kwC4pQQV2XHk+AKR+7uMvnOC Iw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDTQoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7 krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO1HS2Mfk9LnINeyzjxiXU/iENK07YvjBO xbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdX saieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQABo4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0w ezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEcG CCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1l cmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djAPBgNV HRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMwggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUF BwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3Bv bGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFz IGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENl cnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29t L2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlo dHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC9jb21tZXJjaWFscm9vdGNhMS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNV HQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJKoZIhvcNAQELBQADggIBAA3hgq7S+/Tr Yxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBbPGWvzdkmbSgYgXo8GxuAon9+HLIjNv68 BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/twQJeRfxHg3I+0Sfwp5xs10YF0Robhrs CRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrTA6045zQTKGzb370whliPLFo+hNL6XzEt y5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCmKCPIVPq/+9GqggGvtakM5K3VXNc9VtKP U9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7yE03nh2jLV7XAkcqad9vS4EB4hKjFFsm cwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6mYkzqrPigPazF2rgYw3lp0B1gSzCRj+j RtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR 8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCmunLMtaZ2vSai7du/VKrg64GGZNAKerEB evjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q/0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJ K32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UE ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU85MI 7zANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTgwMTI1MTUwNjM5WjAvBgkqhkiG9w0BCQQxIgQg2nAT38aa/r59Hh8HReOi V2jaQ5t2kjX8wWVbDlVjPGAwXQYJKwYBBAGCNxAEMVAwTjA6MQswCQYDVQQGEwJVUzESMBAG A1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU 85MI7zBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5U cnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABXuA9GK1yuUawlPOTCO8wbAYJKoZI hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQAh9NCxH+xRB63eq8h1BHekNqwsVexRsj0t/akdfxUnMeAx1dEgMYOy Dw9IO4xswrSldJAanT8Yevgx7YByt/V0K/BOxtybwNEj6clArU4XbKzND+KogahvvpIRoFC/ gD3eHG6WhC1eb+gC93AUMOgZu5JOy/6JgFhMWtw2/sT5iHk92BKmWcmamkG0OxzrY9xXwB3w UvOQGwg08rREaz1UQhbuNZNkmausqPTiTqPmCR4r86shRsyeYYqes89oidJtmBkMmhk43Lxx k+7QB41f4Kxtk7fFPeelrowa9m5ISz3WjF77LSrtc71Fh6NPSOTCEaKPaPRmOmes9Que3rJ8 AAAAAAAA --------------ms080800090301030402050401-- From xmgu@royole.com Thu Jan 25 22:50:35 2018 From: xmgu@royole.com (Ximeng Guan) Date: Thu, 25 Jan 2018 22:50:35 +0000 Subject: [OpenAFS] Is member of a machine group honored as system:authuser? In-Reply-To: <20180125041423.GN3284@kduck.kaduk.org> References: <6d5952d7576942e4a8c521aa403861de@royole.com> <20180125041423.GN3284@kduck.kaduk.org> Message-ID: SGkgQmVuLCBHYXJhbmNlIGFuZCBKZWZmcmV5LA0KDQpUaGFuayB5b3UgYWxsIGZvciB0aGUgY2xh cmlmaWNhdGlvbiBhbmQgYWR2aWNlLiANCg0KRm9yIG5vdyBJIHdpbGwgZm9sbG93IEdhcmFuY2Un cyBzdWdnZXN0aW9uIHRvIGNyZWF0ZSBhIGNvbW1vbiBtYWNoaW5lIGdyb3VwIGFuZCB1c2UgaXQg dG8gb3BlbiB1cCB0aGUgcGF0aCBmcm9tIC9hZnMgZG93biB0byB0aGUgcG9pbnQgd2hlcmUgYSBz cGVjaWZpYyBtYWNoaW5lIGdyb3VwIGlzIG5lZWRlZCwgYW5kIHRoZW4gdXNlIHRoZSBzcGVjaWZp YyBtYWNoaW5lIGdyb3VwIGZyb20gdGhlcmUuIA0KDQpUaGFua3MgdG8gSmVmZnJleSBmb3IgcG9p bnRpbmcgb3V0IHRoZSBwb3RlbnRpYWwgcmlza3Mgb2YgdXNpbmcgbWFjaGluZSBiYXNlZCBBQ0wg KGRhdGEgaW50ZWdyaXR5IGFuZCB3aXJlIHByaXZhY3kgdW5wcm90ZWN0ZWQpIGluIE9wZW5BRlMu IEl0IGlzIGdyZWF0IHRvIGxlYXJuIHRoYXQgQXVyaXN0b3IgaGFzIGRldmVsb3BlZCBhbmQgY29t bWVyY2lhbGl6ZWQgYSBzb2x1dGlvbiB0byB0aGlzLCB3aGljaCBhIHN0YXJ0dXAgbGlrZSB1cyBj YW4gbGF0ZXIgb24gdHVybiB0byBmb3Igc3VwcG9ydCB3aGVuIHdlIGdyb3cuIA0KDQpJIHJlYWxp emUgdGhhdCBteSBuZWVkIGZvciBhIG1hY2hpbmUtYmFzZWQgYWNjZXNzIGFjdHVhbGx5IGhhcyB0 d28gZm9sZHM6IE9uIHRoZSBvbmUgaGFuZCB3ZSB3YW50IHRvIHByb3RlY3QgdGhlIHNvZnR3YXJl IGluc3RhbGxhdGlvbiBwYXRoIHNvIHRoYXQgaXQgY2FuIGJlIGFjY2Vzc2VkIGJ5IHVzZXJzIG9m IG1hY2hpbmVzIGZyb20gYSBjZXJ0YWluIG9mZmljZSBvciBnZW9ncmFwaGljIGxvY2F0aW9uLiBP biB0aGUgb3RoZXIgaGFuZCB3ZSB3YW50IHRob3NlIHBhcnRpY3VsYXIgbWFjaGluZXMgdG8gZ2Fp biBhY2Nlc3MgdG8gdGhlIGluc3RhbGxhdGlvbiBwYXRoIGF0IGJvb3Qgd2l0aG91dCBhbnkgaHVt YW4gaW50ZXJmZXJlbmNlLiANCg0KVGhlIGFjdHVhbCBzY2VuYXJpbyBpcyB0aGF0IHRoZXJlIGFy ZSBkYWVtb24gc2VydmljZSBiaW5hcmllcyBpbiB0aGF0IGluc3RhbGxhdGlvbiBwYXRoIHdoaWNo IHdlIHdvdWxkIGxpa2UgZWFjaCBtYWNoaW5lIG9mIHRoZSBncm91cCB0byBsYXVuY2ggYnkgaXRz IGxvY2FsIHJvb3QsIGV2ZXJ5IHRpbWUgdGhlIG1hY2hpbmUgaXMgcmVib290ZWQgKHRocm91Z2gg U3lzVmluaXQgc2NyaXB0IG9yIHN5c3RlbWQpLiBZb3UgbWF5IHRoaW5rIG9mIHRob3NlIG1hY2hp bmVzIGFzIHRoZSB3b3JraG9yc2UgcGFydCBvZiBhIHNpbXVsYXRpb24gcHJvZ3JhbSB0aGF0IGxp c3RlbnMgb24gY2VydGFpbiBwb3J0IGZvciBqb2Igc3VibWlzc2lvbnMgYnkgY2xpZW50IHVzZXJz LiBUaGUgcHJvZ3JhbSBpcyBwYXJhbGxlbGl6ZWQgYnkgTVBJIGFuZCBjYW4gcG90ZW50aWFsbHkg ZGlzdHJpYnV0ZSBhIHNpbXVsYXRpb24gam9iIGFtb25nIHRob3NlIG1hY2hpbmVzLiANCg0KSW4g b3RoZXIgd29yZHMgd2hpbGUgd2UgZG8gd2FudCB0byBibG9jayBtYWNoaW5lcyBvdXQgb2YgdGhl IG1hY2hpbmUgZ3JvdXAgZnJvbSBhY2Nlc3NpbmcgdGhlIEFGUyBwYXRoLCBmb3IgdGhvc2UgaW4g dGhlIG1hY2hpbmUgZ3JvdXAgd2Ugd291bGQgbGlrZSB0aGVtIHRvIGdhaW4gYWNjZXNzIHRvIHRo ZSBzcGVjaWZpYyBBRlMgcGF0aCBhdCBib290LCByaWdodCBhZnRlciB0aGUgQUZTIHNlcnZpY2Ug aXMgdXAgYnV0IHByZWZlcmFibHkgd2l0aG91dCB0aGUgbmVlZCBvZiBhbnkgaHVtYW4gdXNlciBh dXRoZW50aWNhdGlvbi4gDQoNCkkgdGhpbmsgdGhhdCdzIGEgbW9yZSBjb21wbGV0ZSBkZXNjcmlw dGlvbiBvZiBteSB1c2FnZSBzY2VuYXJpby4gSSBob3BlIHRoaXMgZGlzY3Vzc2lvbiBoZWxwcyBv dGhlcnMgd2hvIG1heSBoYXZlIHNpbWlsYXIgbmVlZCBpbiB0aGUgZnV0dXJlLiANCg0KQnkgdGhl IHdheSBjYW4gc29tZW9uZSBraW5kbHkgcmVwbHkgdGhpcyBtZXNzYWdlIHNvIHRoYXQgaXQgZG9l cyBub3QgYXBwZWFyIHRvIGJlIGVuY3J5cHRlZCBpbiB0aGUgYXJjaGl2ZT8gU29tZWhvdyBJIGZv dW5kIG15IG9yaWdpbmFsIG1lc3NhZ2UgdG8gc2hvdyB1cCBhcyBlbmNyeXB0ZWQgaW4gdGhlIGFy Y2hpdmUuIA0KDQpUaGFua3MuIA0KDQpYaW1lbmcgKFNpbW9uKQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQmVuamFtaW4gS2FkdWsgW21haWx0bzprYWR1a0BtaXQuZWR1XSAN ClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNCwgMjAxOCA4OjE0IFBNDQpUbzogWGltZW5nIEd1 YW4gPHhtZ3VAcm95b2xlLmNvbT4NCkNjOiBvcGVuYWZzLWluZm9Ab3BlbmFmcy5vcmcNClN1Ympl Y3Q6IFJlOiBbT3BlbkFGU10gSXMgbWVtYmVyIG9mIGEgbWFjaGluZSBncm91cCBob25vcmVkIGFz IHN5c3RlbTphdXRodXNlcj8NCg0KT24gV2VkLCBKYW4gMjQsIDIwMTggYXQgMDc6MzE6NTFQTSAr MDAwMCwgWGltZW5nIEd1YW4gd3JvdGU6DQoNCltzbmlwXQ0KPiBEaWQgSSBtaXNzIGFueXRoaW5n IGhlcmU/IA0KDQpJIGRvbid0IHRoaW5rIHNvLiAgSXQncyBwcm9iYWJseSBiZXN0IHRvIHRoaW5r IG9mIHN5c3RlbTphdXRodXNlciBhcyBhIHNob3J0aGFuZCBmb3IgImFsbCBlbnRpdGllcyB0aGF0 IGNhbiBhdXRoZW50aWNhdGUgdG8gdGhlIHByb3RlY3Rpb24gc2VydmVyIiwgdXNlcnMgYW5kIGtl eXRhYi1iYXNlZCBjcmVkZW50aWFscy4gIFRoZSBtYWNoaW5lL0lQIHByZGIgZW50cmllcyBhcmUg aW4gYW4gaW50ZXJtZWRpYXRlIHNwYWNlLCBpbiB3aGljaCB0aGV5IGNhbiBhcHBlYXIgb24gYWNj ZXNzIGNvbnRyb2wgbGlzdHMgYnV0IG5vdGhpbmcgY2FuIGFjdHVhbGx5IGF1dGhlbnRpY2F0ZSBk aXJlY3RseSBhcyB0aG9zZSBwdHMgZW50cmllcy4gIEl0IHNlZW1zIGxpa2UgYSB3ZWlyZCBkZXNp Z24gY2hvaWNlIG5vdywgYnV0IHByb2JhYmx5IG1hZGUgc2Vuc2UgYSB0aGUgdGltZS4NCnB0c19j cmVhdGV1c2VyKDEpIGhhcyBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBhY3R1YWwgZnVuY3Rp b25hbGl0eS4NCg0KR2FyYW5jZSdzIHN1Z2dlc3Rpb24gb2YgKGVzc2VudGlhbGx5KSBhZGRpbmcg YW4gYWRkaXRpb25hbCBsYXllciBvZiBhYnN0cmFjdGlvbiBzZWVtcyB0byBiZSB0aGUgYmVzdCBw cmFjdGljZSBmb3IgdGhpcyBhcmVhLg0KDQotQmVuDQo= From drosih@rpi.edu Fri Jan 26 21:45:45 2018 From: drosih@rpi.edu (Garance A Drosehn) Date: Fri, 26 Jan 2018 16:45:45 -0500 Subject: [OpenAFS] Is member of a machine group honored as system:authuser? In-Reply-To: References: <6d5952d7576942e4a8c521aa403861de@royole.com> <20180125041423.GN3284@kduck.kaduk.org> Message-ID: On 25 Jan 2018, at 17:50, Ximeng Guan wrote: > > The actual scenario is that there are daemon service binaries in that > installation path which we would like each machine of the group to > launch by its local root, every time the machine is rebooted (through > SysVinit script or systemd). You may think of those machines as the > workhorse part of a simulation program that listens on certain port > for job submissions by client users. The program is parallelized by > MPI and can potentially distribute a simulation job among those > machines. > > In other words while we do want to block machines out of the machine > group from accessing the AFS path, for those in the machine group we > would like them to gain access to the specific AFS path at boot, right > after the AFS service is up but preferably without the need of any > human user authentication. > > I think that's a more complete description of my usage scenario. I > hope this discussion helps others who may have similar need in the > future. Hmm. Well, there's another tactic which I use in a few situations. I'm not sure if it would work for yours. I create a host-specific key in our krb5 database. I take that and put it in the appropriate file under /etc on the machine which needs access. I then do a 'pts createuser rcmd.', where is the short hostname of the host in question. So I might create a krb5 hostkey for 'host/garance.test.rpi.edu@RPI.EDU', and add a PTS user for 'rcmd.garance'. Then if I am logged in as root on that machine, I can type: kinit -k # no password needed aklog # no password needed And then 'root' will have access to things which have been permitted to rcmd.garance in our campus space. This is different than machine-group tactic, because it is only userid root on that machine who will have access to the directories which have been permitted to rcmd.. Other users on the same machine will not gain access. But if your daemon service binaries are running as root, then maybe that'll work for you. You'd also have to pay attention to token-expiration times, which you wouldn't have to do with machine-groups. Then to get rid of access you could do: unlog kdestroy But note that means that ALL root-owned processes will lose access. So if you have multiple daemons using aklog, then unlogging from one of them will cause all of them to lose access. So that's a significant concern when doing unlog/kdestroy. Yet another tactic we do is to create some fake user in PTS, and stash away the password to it somewhere where it is "safe" (say, as a file inside of /etc/security). We could then have some daemon process start up use that hidden password to authenticate to the fake user, and then that daemon will have access to the directories permitted to the fake user. Once again you'd have to pay attention to token-expiration times (via one method or another). All of these were initially used at RPI before I took over maintenance of the AFS cell at RPI, and I suspect that which method was used depended on who was setting up the daemon or other service. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From xmgu@royole.com Fri Jan 26 23:11:10 2018 From: xmgu@royole.com (Ximeng Guan) Date: Fri, 26 Jan 2018 23:11:10 +0000 Subject: [OpenAFS] Is member of a machine group honored as system:authuser? In-Reply-To: References: <6d5952d7576942e4a8c521aa403861de@royole.com> <20180125041423.GN3284@kduck.kaduk.org> Message-ID: <0c9354d0fc8141239de5a2303d4598a5@royole.com> --_000_0c9354d0fc8141239de5a2303d4598a5royolecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBpZGVhIHNlZW1zIHNpbWlsYXIgdG8gdGhlIHN1Z2dlc3Rpb24gYnkgUnVzcyBiYWNrIGlu IDIwMDIgb24gcnVubmluZyBBcGFjaGUNCg0KDQoNCmh0dHBzOi8vbGlzdHMub3BlbmFmcy5vcmcv cGlwZXJtYWlsL29wZW5hZnMtaW5mby8yMDAyLU1heS8wMDQ0NDAuaHRtbA0KDQoNCg0KSSBndWVz cyB0aGUgaWRlYSBpcyB0byBiaW5kIHRoZSBtYWNoaW5lIChvciB0aGUgQUZTIGRpcmVjdG9yeSkg dG8gYSBkZWRpY2F0ZWQgS2VyYmVyb3MgcHJpbmNpcGFsLg0KDQoNCg0KSSBndWVzcyBJIGNhbiBj cmVhdGUgYSBLZXJiZXJvcyBwcmluY2lwYWwgYW5kIGNyZWF0ZSB0aGUgY29ycmVzcG9uZGluZyBw dHMgZW50cnksIGV4cG9ydCB0aGUga2V5dGFiIHRvIGEgZmlsZSBhbmQgc3RvcmUgaXQgaW4gdGhv c2UgbWFjaGluZXMnIGxvY2FsIGRpcmVjdG9yeSwgb25lIHdoaWNoIGNhbiBvbmx5IGJlIGFjY2Vz c2VkIGJ5IHJvb3QuIFRoZW4gc29tZWhvdyBtb2RpZnkgdGhlIHNlcnZpY2UgbGF1bmNoIHNjcmlw dCB0byB1c2UgUnVzcydzIGs1c3RhcnQ8aHR0cHM6Ly93d3cuZXlyaWUub3JnL35lYWdsZS9zb2Z0 d2FyZS9rc3RhcnQvazVzdGFydC5odG1sPiB0byBvYnRhaW4gYSB0b2tlbiBhbmQgc3RhcnQgdGhl IGRhZW1vbiBiaW5hcnkgaW4gdGhlIHByb3RlY3RlZCBBRlMgZGlyZWN0b3J5Lg0KDQoNCg0KVGhh dCB3YXkgdGhlIHdpcmUgcHJpdmFjeSBpcyBtYWludGFpbmVkIGJ5IHRoZSBlbmNyeXB0aW9uLiBU aGUgcG90ZW50aWFsIHJpc2sgaXMgdGhhdCBpZiBhIHVuYXV0aG9yaXplZCB1c2VyIGdhaW5zIHJv b3Qgb24gdGhlIG1hY2hpbmUsIGhlL3NoZSBtYXkgYmUgYWJsZSB0byBhY2Nlc3MgdGhlIEFGUyBk aXJlY3RvcnkuIEJ1dCB0aGF0IGlzIG5vIHdvcnNlIHRoYW4gYW4gSVAtYmFzZWQgbWV0aG9kIHdo ZXJlIGV2ZXJ5IHVzZXIgb2YgdGhhdCBtYWNoaW5lIHdpbGwgYmUgYWJsZSB0byBnZXQgYWNjZXNz IHRvIHRoYXQgZGlyZWN0b3J5Lg0KDQoNCg0KSXQgc2VlbXMgZG9hYmxlLCBleGNlcHQgdGhhdCBJ IGFtIG5vdCB0aGUgYWRtaW4gb2Ygb3VyIEtlcmJlcm9zIGRvbWFpbuKApiBCdXQgSSBjYW4gZmln dXJlIHRoYXQgb3V0Lg0KDQoNCg0KVGhhbmtzIQ0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpTaW1v bg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEdhcmFuY2UgQSBEcm9z ZWhuIFttYWlsdG86ZHJvc2loQHJwaS5lZHVdDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjYsIDIw MTggMTo0NiBQTQ0KVG86IFhpbWVuZyBHdWFuIDx4bWd1QHJveW9sZS5jb20+DQpDYzogb3BlbmFm cy1pbmZvQG9wZW5hZnMub3JnDQpTdWJqZWN0OiBSZTogW09wZW5BRlNdIElzIG1lbWJlciBvZiBh IG1hY2hpbmUgZ3JvdXAgaG9ub3JlZCBhcyBzeXN0ZW06YXV0aHVzZXI/DQoNCg0KDQpPbiAyNSBK YW4gMjAxOCwgYXQgMTc6NTAsIFhpbWVuZyBHdWFuIHdyb3RlOg0KDQo+DQoNCj4gVGhlIGFjdHVh bCBzY2VuYXJpbyBpcyB0aGF0IHRoZXJlIGFyZSBkYWVtb24gc2VydmljZSBiaW5hcmllcyBpbiB0 aGF0DQoNCj4gaW5zdGFsbGF0aW9uIHBhdGggd2hpY2ggd2Ugd291bGQgbGlrZSBlYWNoIG1hY2hp bmUgb2YgdGhlIGdyb3VwIHRvDQoNCj4gbGF1bmNoIGJ5IGl0cyBsb2NhbCByb290LCBldmVyeSB0 aW1lIHRoZSBtYWNoaW5lIGlzIHJlYm9vdGVkICh0aHJvdWdoDQoNCj4gU3lzVmluaXQgc2NyaXB0 IG9yIHN5c3RlbWQpLiBZb3UgbWF5IHRoaW5rIG9mIHRob3NlIG1hY2hpbmVzIGFzIHRoZQ0KDQo+ IHdvcmtob3JzZSBwYXJ0IG9mIGEgc2ltdWxhdGlvbiBwcm9ncmFtIHRoYXQgbGlzdGVucyBvbiBj ZXJ0YWluIHBvcnQNCg0KPiBmb3Igam9iIHN1Ym1pc3Npb25zIGJ5IGNsaWVudCB1c2Vycy4gVGhl IHByb2dyYW0gaXMgcGFyYWxsZWxpemVkIGJ5DQoNCj4gTVBJIGFuZCBjYW4gcG90ZW50aWFsbHkg ZGlzdHJpYnV0ZSBhIHNpbXVsYXRpb24gam9iIGFtb25nIHRob3NlDQoNCj4gbWFjaGluZXMuDQoN Cj4NCg0KPiBJbiBvdGhlciB3b3JkcyB3aGlsZSB3ZSBkbyB3YW50IHRvIGJsb2NrIG1hY2hpbmVz IG91dCBvZiB0aGUgbWFjaGluZQ0KDQo+IGdyb3VwIGZyb20gYWNjZXNzaW5nIHRoZSBBRlMgcGF0 aCwgZm9yIHRob3NlIGluIHRoZSBtYWNoaW5lIGdyb3VwIHdlDQoNCj4gd291bGQgbGlrZSB0aGVt IHRvIGdhaW4gYWNjZXNzIHRvIHRoZSBzcGVjaWZpYyBBRlMgcGF0aCBhdCBib290LCByaWdodA0K DQo+IGFmdGVyIHRoZSBBRlMgc2VydmljZSBpcyB1cCBidXQgcHJlZmVyYWJseSB3aXRob3V0IHRo ZSBuZWVkIG9mIGFueQ0KDQo+IGh1bWFuIHVzZXIgYXV0aGVudGljYXRpb24uDQoNCj4NCg0KPiBJ IHRoaW5rIHRoYXQncyBhIG1vcmUgY29tcGxldGUgZGVzY3JpcHRpb24gb2YgbXkgdXNhZ2Ugc2Nl bmFyaW8uIEkNCg0KPiBob3BlIHRoaXMgZGlzY3Vzc2lvbiBoZWxwcyBvdGhlcnMgd2hvIG1heSBo YXZlIHNpbWlsYXIgbmVlZCBpbiB0aGUNCg0KPiBmdXR1cmUuDQoNCg0KDQpIbW0uICBXZWxsLCB0 aGVyZSdzIGFub3RoZXIgdGFjdGljIHdoaWNoIEkgdXNlIGluIGEgZmV3IHNpdHVhdGlvbnMuICBJ J20gbm90IHN1cmUgaWYgaXQgd291bGQgd29yayBmb3IgeW91cnMuDQoNCg0KDQpJIGNyZWF0ZSBh IGhvc3Qtc3BlY2lmaWMga2V5IGluIG91ciBrcmI1IGRhdGFiYXNlLiAgSSB0YWtlIHRoYXQgYW5k IHB1dCBpdCBpbiB0aGUgYXBwcm9wcmlhdGUgZmlsZSB1bmRlciAvZXRjIG9uIHRoZSBtYWNoaW5l IHdoaWNoIG5lZWRzIGFjY2Vzcy4NCg0KICBJIHRoZW4gZG8gYSAncHRzIGNyZWF0ZXVzZXIgcmNt ZC48aG9zdD4nLCB3aGVyZSA8aG9zdD4gaXMgdGhlIHNob3J0IGhvc3RuYW1lIG9mIHRoZSBob3N0 IGluIHF1ZXN0aW9uLiAgU28gSSBtaWdodCBjcmVhdGUgYSBrcmI1IGhvc3RrZXkgZm9yICdob3N0 L2dhcmFuY2UudGVzdC5ycGkuZWR1QFJQSS5FRFUnLCBhbmQgYWRkIGEgUFRTIHVzZXIgZm9yICdy Y21kLmdhcmFuY2UnLg0KDQoNCg0KVGhlbiBpZiBJIGFtIGxvZ2dlZCBpbiBhcyByb290IG9uIHRo YXQgbWFjaGluZSwgSSBjYW4gdHlwZToNCg0KDQoNCmtpbml0IC1rICAgICAgICAgICAgICAgICAg ICAgICAgICMgbm8gcGFzc3dvcmQgbmVlZGVkDQoNCmFrbG9nICAgICAgICAgICAgICAgICAgICAg ICAgICAgIyBubyBwYXNzd29yZCBuZWVkZWQNCg0KDQoNCkFuZCB0aGVuICdyb290JyB3aWxsIGhh dmUgYWNjZXNzIHRvIHRoaW5ncyB3aGljaCBoYXZlIGJlZW4gcGVybWl0dGVkIHRvIHJjbWQuZ2Fy YW5jZSBpbiBvdXIgY2FtcHVzIHNwYWNlLiAgVGhpcyBpcyBkaWZmZXJlbnQgdGhhbiBtYWNoaW5l LWdyb3VwIHRhY3RpYywgYmVjYXVzZSBpdCBpcyBvbmx5IHVzZXJpZCByb290IG9uIHRoYXQgbWFj aGluZSB3aG8gd2lsbCBoYXZlIGFjY2VzcyB0byB0aGUgZGlyZWN0b3JpZXMgd2hpY2ggaGF2ZSBi ZWVuIHBlcm1pdHRlZCB0byByY21kLjxob3N0Pi4NCg0KT3RoZXIgdXNlcnMgb24gdGhlIHNhbWUg bWFjaGluZSB3aWxsIG5vdCBnYWluIGFjY2Vzcy4NCg0KDQoNCkJ1dCBpZiB5b3VyIGRhZW1vbiBz ZXJ2aWNlIGJpbmFyaWVzIGFyZSBydW5uaW5nIGFzIHJvb3QsIHRoZW4gbWF5YmUgdGhhdCdsbCB3 b3JrIGZvciB5b3UuICBZb3UnZCBhbHNvIGhhdmUgdG8gcGF5IGF0dGVudGlvbiB0byB0b2tlbi1l eHBpcmF0aW9uIHRpbWVzLCB3aGljaCB5b3Ugd291bGRuJ3QgaGF2ZSB0byBkbyB3aXRoIG1hY2hp bmUtZ3JvdXBzLg0KDQoNCg0KVGhlbiB0byBnZXQgcmlkIG9mIGFjY2VzcyB5b3UgY291bGQgZG86 DQoNCg0KDQp1bmxvZw0KDQprZGVzdHJveQ0KDQoNCg0KQnV0IG5vdGUgdGhhdCBtZWFucyB0aGF0 IEFMTCByb290LW93bmVkIHByb2Nlc3NlcyB3aWxsIGxvc2UgYWNjZXNzLiAgU28gaWYgeW91IGhh dmUgbXVsdGlwbGUgZGFlbW9ucyB1c2luZyBha2xvZywgdGhlbiB1bmxvZ2dpbmcgZnJvbSBvbmUg b2YgdGhlbSB3aWxsIGNhdXNlIGFsbCBvZiB0aGVtIHRvIGxvc2UgYWNjZXNzLiAgU28gdGhhdCdz IGEgc2lnbmlmaWNhbnQgY29uY2VybiB3aGVuIGRvaW5nIHVubG9nL2tkZXN0cm95Lg0KDQoNCg0K WWV0IGFub3RoZXIgdGFjdGljIHdlIGRvIGlzIHRvIGNyZWF0ZSBzb21lIGZha2UgdXNlciBpbiBQ VFMsIGFuZCBzdGFzaCBhd2F5IHRoZSBwYXNzd29yZCB0byBpdCBzb21ld2hlcmUgd2hlcmUgaXQg aXMgInNhZmUiIChzYXksIGFzIGEgZmlsZSBpbnNpZGUgb2YgL2V0Yy9zZWN1cml0eSkuICBXZSBj b3VsZCB0aGVuIGhhdmUgc29tZSBkYWVtb24gcHJvY2VzcyBzdGFydCB1cCB1c2UgdGhhdCBoaWRk ZW4gcGFzc3dvcmQgdG8gYXV0aGVudGljYXRlIHRvIHRoZSBmYWtlIHVzZXIsIGFuZCB0aGVuIHRo YXQgZGFlbW9uIHdpbGwgaGF2ZSBhY2Nlc3MgdG8gdGhlIGRpcmVjdG9yaWVzIHBlcm1pdHRlZCB0 byB0aGUgZmFrZSB1c2VyLiAgT25jZSBhZ2FpbiB5b3UnZCBoYXZlIHRvIHBheSBhdHRlbnRpb24g dG8gdG9rZW4tZXhwaXJhdGlvbiB0aW1lcyAodmlhIG9uZSBtZXRob2Qgb3IgYW5vdGhlcikuDQoN Cg0KDQpBbGwgb2YgdGhlc2Ugd2VyZSBpbml0aWFsbHkgdXNlZCBhdCBSUEkgYmVmb3JlIEkgdG9v ayBvdmVyIG1haW50ZW5hbmNlIG9mIHRoZSBBRlMgY2VsbCBhdCBSUEksIGFuZCBJIHN1c3BlY3Qg dGhhdCB3aGljaCBtZXRob2Qgd2FzIHVzZWQgZGVwZW5kZWQgb24gd2hvIHdhcyBzZXR0aW5nIHVw IHRoZSBkYWVtb24gb3Igb3RoZXIgc2VydmljZS4NCg0KDQoNCi0tDQoNCkdhcmFuY2UgQWxpc3Rh aXIgRHJvc2VobiAgICAgICAgICAgICAgICA9ICAgICBkcm9zaWhAcnBpLmVkdTxtYWlsdG86ZHJv c2loQHJwaS5lZHU+DQoNClNlbmlvciBTeXN0ZW1zIFByb2dyYW1tZXIgICAgICAgICAgICAgICBv ciAgIGdhZEBGcmVlQlNELm9yZzxtYWlsdG86Z2FkQEZyZWVCU0Qub3JnPg0KDQpSZW5zc2VsYWVy IFBvbHl0ZWNobmljIEluc3RpdHV0ZTsgICAgICAgICAgICAgVHJveSwgTlk7ICBVU0ENCg== --_000_0c9354d0fc8141239de5a2303d4598a5royolecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBs YWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj OTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaGF0IGlkZWEgc2VlbXMgc2ltaWxhciB0byB0aGUgc3VnZ2VzdGlvbiBieSBSdXNzIGJh Y2sgaW4gMjAwMiBvbiBydW5uaW5nIEFwYWNoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48YSBocmVmPSJodHRwczovL2xpc3RzLm9wZW5hZnMub3JnL3BpcGVybWFpbC9vcGVuYWZzLWlu Zm8vMjAwMi1NYXkvMDA0NDQwLmh0bWwiPmh0dHBzOi8vbGlzdHMub3BlbmFmcy5vcmcvcGlwZXJt YWlsL29wZW5hZnMtaW5mby8yMDAyLU1heS8wMDQ0NDAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+SSBndWVzcyB0aGUgaWRlYSBpcyB0byBiaW5kIHRoZSBtYWNoaW5lIChv ciB0aGUgQUZTIGRpcmVjdG9yeSkgdG8gYSBkZWRpY2F0ZWQgS2VyYmVyb3MgcHJpbmNpcGFsLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgZ3Vlc3MgSSBjYW4gY3JlYXRlIGEgS2Vy YmVyb3MgcHJpbmNpcGFsIGFuZCBjcmVhdGUgdGhlIGNvcnJlc3BvbmRpbmcgcHRzIGVudHJ5LCBl eHBvcnQgdGhlIGtleXRhYiB0byBhIGZpbGUgYW5kIHN0b3JlIGl0IGluIHRob3NlIG1hY2hpbmVz JyBsb2NhbCBkaXJlY3RvcnksIG9uZSB3aGljaCBjYW4gb25seSBiZSBhY2Nlc3NlZCBieSByb290 LiBUaGVuIHNvbWVob3cgbW9kaWZ5IHRoZSBzZXJ2aWNlIGxhdW5jaA0KIHNjcmlwdCB0byB1c2Ug UnVzcydzIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmV5cmllLm9yZy9+ZWFnbGUvc29mdHdhcmUva3N0 YXJ0L2s1c3RhcnQuaHRtbCI+DQprNXN0YXJ0PC9hPiB0byBvYnRhaW4gYSB0b2tlbiBhbmQgc3Rh cnQgdGhlIGRhZW1vbiBiaW5hcnkgaW4gdGhlIHByb3RlY3RlZCBBRlMgZGlyZWN0b3J5Lg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYXQgd2F5IHRoZSB3aXJlIHByaXZhY3kgaXMg bWFpbnRhaW5lZCBieSB0aGUgZW5jcnlwdGlvbi4gVGhlIHBvdGVudGlhbCByaXNrIGlzIHRoYXQg aWYgYSB1bmF1dGhvcml6ZWQgdXNlciBnYWlucyByb290IG9uIHRoZSBtYWNoaW5lLCBoZS9zaGUg bWF5IGJlIGFibGUgdG8gYWNjZXNzIHRoZSBBRlMgZGlyZWN0b3J5LiBCdXQgdGhhdCBpcyBubyB3 b3JzZSB0aGFuIGFuIElQLWJhc2VkIG1ldGhvZCB3aGVyZQ0KIGV2ZXJ5IHVzZXIgb2YgdGhhdCBt YWNoaW5lIHdpbGwgYmUgYWJsZSB0byBnZXQgYWNjZXNzIHRvIHRoYXQgZGlyZWN0b3J5LiA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SXQgc2VlbXMgZG9hYmxlLCBleGNlcHQgdGhhdCBJ IGFtIG5vdCB0aGUgYWRtaW4gb2Ygb3VyIEtlcmJlcm9zIGRvbWFpbuKApiBCdXQgSSBjYW4gZmln dXJlIHRoYXQgb3V0Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyE8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2ltb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBHYXJhbmNlIEEgRHJvc2Vo biBbbWFpbHRvOmRyb3NpaEBycGkuZWR1XSA8YnI+DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjYs IDIwMTggMTo0NiBQTTxicj4NClRvOiBYaW1lbmcgR3VhbiAmbHQ7eG1ndUByb3lvbGUuY29tJmd0 Ozxicj4NCkNjOiBvcGVuYWZzLWluZm9Ab3BlbmFmcy5vcmc8YnI+DQpTdWJqZWN0OiBSZTogW09w ZW5BRlNdIElzIG1lbWJlciBvZiBhIG1hY2hpbmUgZ3JvdXAgaG9ub3JlZCBhcyBzeXN0ZW06YXV0 aHVzZXI/PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PbiAyNSBKYW4gMjAxOCwgYXQgMTc6NTAsIFhpbWVu ZyBHdWFuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUg YWN0dWFsIHNjZW5hcmlvIGlzIHRoYXQgdGhlcmUgYXJlIGRhZW1vbiBzZXJ2aWNlIGJpbmFyaWVz IGluIHRoYXQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBp bnN0YWxsYXRpb24gcGF0aCB3aGljaCB3ZSB3b3VsZCBsaWtlIGVhY2ggbWFjaGluZSBvZiB0aGUg Z3JvdXAgdG8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBs YXVuY2ggYnkgaXRzIGxvY2FsIHJvb3QsIGV2ZXJ5IHRpbWUgdGhlIG1hY2hpbmUgaXMgcmVib290 ZWQgKHRocm91Z2gNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBTeXNWaW5pdCBzY3JpcHQgb3Igc3lzdGVtZCkuIFlvdSBtYXkgdGhpbmsgb2YgdGhvc2UgbWFj aGluZXMgYXMgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgd29ya2hvcnNlIHBhcnQgb2YgYSBzaW11bGF0aW9uIHByb2dyYW0gdGhhdCBsaXN0ZW5zIG9u IGNlcnRhaW4gcG9ydA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGZvciBqb2Igc3VibWlzc2lvbnMgYnkgY2xpZW50IHVzZXJzLiBUaGUgcHJvZ3JhbSBpcyBw YXJhbGxlbGl6ZWQgYnkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBNUEkgYW5kIGNhbiBwb3RlbnRpYWxseSBkaXN0cmlidXRlIGEgc2ltdWxhdGlvbiBqb2Ig YW1vbmcgdGhvc2UNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBtYWNoaW5lcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSW4gb3Ro ZXIgd29yZHMgd2hpbGUgd2UgZG8gd2FudCB0byBibG9jayBtYWNoaW5lcyBvdXQgb2YgdGhlIG1h Y2hpbmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBncm91 cCBmcm9tIGFjY2Vzc2luZyB0aGUgQUZTIHBhdGgsIGZvciB0aG9zZSBpbiB0aGUgbWFjaGluZSBn cm91cCB3ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdv dWxkIGxpa2UgdGhlbSB0byBnYWluIGFjY2VzcyB0byB0aGUgc3BlY2lmaWMgQUZTIHBhdGggYXQg Ym9vdCwgcmlnaHQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBhZnRlciB0aGUgQUZTIHNlcnZpY2UgaXMgdXAgYnV0IHByZWZlcmFibHkgd2l0aG91dCB0aGUg bmVlZCBvZiBhbnkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBodW1hbiB1c2VyIGF1dGhlbnRpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBJIHRoaW5rIHRoYXQncyBhIG1vcmUgY29tcGxldGUgZGVzY3JpcHRpb24gb2Yg bXkgdXNhZ2Ugc2NlbmFyaW8uIEkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBob3BlIHRoaXMgZGlzY3Vzc2lvbiBoZWxwcyBvdGhlcnMgd2hvIG1heSBoYXZl IHNpbWlsYXIgbmVlZCBpbiB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBmdXR1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhtbS4mbmJz cDsgV2VsbCwgdGhlcmUncyBhbm90aGVyIHRhY3RpYyB3aGljaCBJIHVzZSBpbiBhIGZldyBzaXR1 YXRpb25zLiZuYnNwOyBJJ20gbm90IHN1cmUgaWYgaXQgd291bGQgd29yayBmb3IgeW91cnMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgY3JlYXRlIGEgaG9zdC1zcGVjaWZpYyBrZXkg aW4gb3VyIGtyYjUgZGF0YWJhc2UuJm5ic3A7IEkgdGFrZSB0aGF0IGFuZCBwdXQgaXQgaW4gdGhl IGFwcHJvcHJpYXRlIGZpbGUgdW5kZXIgL2V0YyBvbiB0aGUgbWFjaGluZSB3aGljaCBuZWVkcyBh Y2Nlc3MuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwO0kgdGhlbiBkbyBhICdwdHMgY3JlYXRldXNlciByY21kLiZsdDtob3N0Jmd0OycsIHdoZXJl ICZsdDtob3N0Jmd0OyBpcyB0aGUgc2hvcnQgaG9zdG5hbWUgb2YgdGhlIGhvc3QgaW4gcXVlc3Rp b24uJm5ic3A7IFNvIEkgbWlnaHQgY3JlYXRlIGEga3JiNSBob3N0a2V5IGZvciAnaG9zdC9nYXJh bmNlLnRlc3QucnBpLmVkdUBSUEkuRURVJywgYW5kIGFkZCBhIFBUUyB1c2VyIGZvciAncmNtZC5n YXJhbmNlJy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlbiBpZiBJIGFtIGxvZ2dl ZCBpbiBhcyByb290IG9uIHRoYXQgbWFjaGluZSwgSSBjYW4gdHlwZTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+a2luaXQgLWsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyBu byBwYXNzd29yZCBuZWVkZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PmFrbG9nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMgbm8gcGFz c3dvcmQgbmVlZGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFuZCB0aGVuICdyb290 JyB3aWxsIGhhdmUgYWNjZXNzIHRvIHRoaW5ncyB3aGljaCBoYXZlIGJlZW4gcGVybWl0dGVkIHRv IHJjbWQuZ2FyYW5jZSBpbiBvdXIgY2FtcHVzIHNwYWNlLiZuYnNwOyBUaGlzIGlzIGRpZmZlcmVu dCB0aGFuIG1hY2hpbmUtZ3JvdXAgdGFjdGljLCBiZWNhdXNlIGl0IGlzIG9ubHkgdXNlcmlkIHJv b3Qgb24gdGhhdCBtYWNoaW5lIHdobyB3aWxsIGhhdmUgYWNjZXNzIHRvIHRoZSBkaXJlY3Rvcmll cw0KIHdoaWNoIGhhdmUgYmVlbiBwZXJtaXR0ZWQgdG8gcmNtZC4mbHQ7aG9zdCZndDsuJm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T3RoZXIgdXNlcnMgb24g dGhlIHNhbWUgbWFjaGluZSB3aWxsIG5vdCBnYWluIGFjY2Vzcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+QnV0IGlmIHlvdXIgZGFlbW9uIHNlcnZpY2UgYmluYXJpZXMgYXJlIHJ1bm5p bmcgYXMgcm9vdCwgdGhlbiBtYXliZSB0aGF0J2xsIHdvcmsgZm9yIHlvdS4mbmJzcDsgWW91J2Qg YWxzbyBoYXZlIHRvIHBheSBhdHRlbnRpb24gdG8gdG9rZW4tZXhwaXJhdGlvbiB0aW1lcywgd2hp Y2ggeW91IHdvdWxkbid0IGhhdmUgdG8gZG8gd2l0aCBtYWNoaW5lLWdyb3Vwcy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlbiB0byBnZXQgcmlkIG9mIGFjY2VzcyB5b3UgY291bGQg ZG86PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnVubG9nPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5rZGVzdHJveTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5CdXQgbm90ZSB0aGF0IG1lYW5zIHRoYXQgQUxMIHJvb3Qtb3duZWQgcHJvY2Vzc2VzIHdp bGwgbG9zZSBhY2Nlc3MuJm5ic3A7IFNvIGlmIHlvdSBoYXZlIG11bHRpcGxlIGRhZW1vbnMgdXNp bmcgYWtsb2csIHRoZW4gdW5sb2dnaW5nIGZyb20gb25lIG9mIHRoZW0gd2lsbCBjYXVzZSBhbGwg b2YgdGhlbSB0byBsb3NlIGFjY2Vzcy4mbmJzcDsgU28gdGhhdCdzIGEgc2lnbmlmaWNhbnQgY29u Y2VybiB3aGVuIGRvaW5nIHVubG9nL2tkZXN0cm95LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5ZZXQgYW5vdGhlciB0YWN0aWMgd2UgZG8gaXMgdG8gY3JlYXRlIHNvbWUgZmFrZSB1c2Vy IGluIFBUUywgYW5kIHN0YXNoIGF3YXkgdGhlIHBhc3N3b3JkIHRvIGl0IHNvbWV3aGVyZSB3aGVy ZSBpdCBpcyAmcXVvdDtzYWZlJnF1b3Q7IChzYXksIGFzIGEgZmlsZSBpbnNpZGUgb2YgL2V0Yy9z ZWN1cml0eSkuJm5ic3A7IFdlIGNvdWxkIHRoZW4gaGF2ZSBzb21lIGRhZW1vbiBwcm9jZXNzIHN0 YXJ0IHVwIHVzZSB0aGF0IGhpZGRlbiBwYXNzd29yZA0KIHRvIGF1dGhlbnRpY2F0ZSB0byB0aGUg ZmFrZSB1c2VyLCBhbmQgdGhlbiB0aGF0IGRhZW1vbiB3aWxsIGhhdmUgYWNjZXNzIHRvIHRoZSBk aXJlY3RvcmllcyBwZXJtaXR0ZWQgdG8gdGhlIGZha2UgdXNlci4mbmJzcDsgT25jZSBhZ2FpbiB5 b3UnZCBoYXZlIHRvIHBheSBhdHRlbnRpb24gdG8gdG9rZW4tZXhwaXJhdGlvbiB0aW1lcyAodmlh IG9uZSBtZXRob2Qgb3IgYW5vdGhlcikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFs bCBvZiB0aGVzZSB3ZXJlIGluaXRpYWxseSB1c2VkIGF0IFJQSSBiZWZvcmUgSSB0b29rIG92ZXIg bWFpbnRlbmFuY2Ugb2YgdGhlIEFGUyBjZWxsIGF0IFJQSSwgYW5kIEkgc3VzcGVjdCB0aGF0IHdo aWNoIG1ldGhvZCB3YXMgdXNlZCBkZXBlbmRlZCBvbiB3aG8gd2FzIHNldHRpbmcgdXAgdGhlIGRh ZW1vbiBvciBvdGhlciBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLSA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkdhcmFuY2UgQWxpc3RhaXIg RHJvc2VobiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpkcm9zaWhAcnBpLmVkdSI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZHJvc2loQHJwaS5lZHU8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VuaW9yIFN5 c3RlbXMgUHJvZ3JhbW1lciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvciZuYnNwOyZuYnNw OyA8YSBocmVmPSJtYWlsdG86Z2FkQEZyZWVCU0Qub3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5nYWRARnJlZUJTRC5vcmc8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UmVuc3NlbGFlciBQb2x5 dGVjaG5pYyBJbnN0aXR1dGU7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRyb3ksIE5ZOyZuYnNwOyBVU0E8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0c9354d0fc8141239de5a2303d4598a5royolecom_-- From andreas.ladanyi@kit.edu Tue Jan 30 13:09:21 2018 From: andreas.ladanyi@kit.edu (Andreas Ladanyi) Date: Tue, 30 Jan 2018 14:09:21 +0100 Subject: [OpenAFS] Windows 10, KDC not reachable / AFS integrated login failed Message-ID: <95033ca8-bfc4-6fa4-36d4-fd2f82db8b17@kit.edu> Hi, Windows 10 Pro , Auristor AFS client package When starting the device and before login screen appears the messages appears: Integrated login failed - unable to reach any KDC in realm ....... or AFS integrated login failed before it is possible to enter credentials at windows login box (display manager). So there is no access to afs path after first login. If login / logout / login then there is access to afs path. So is the kerberos /afs client starting too early before network settings are set ? Is it possible to start kerberos client and afs client after entering the credentials at windows 10 ? regards, Andreas From utoddl@email.unc.edu Tue Jan 30 21:20:03 2018 From: utoddl@email.unc.edu (Todd Lewis) Date: Tue, 30 Jan 2018 16:20:03 -0500 Subject: [OpenAFS] convert 'vos dump' output to tar or zip? Message-ID: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> Has anybody a tool to convert "vos dump" output to a tar or zip format? Is the "vos dump" format usable by anything other than "vos restore"? -- +--------------------------------------------------------------+ / Todd_Lewis@unc.edu 919-445-0091 http://www.unc.edu/~utoddl / / "I've had a perfectly wonderful evening. / / But this wasn't it." - Groucho Marx / +--------------------------------------------------------------+ From turbo@bayour.com Tue Jan 30 21:23:42 2018 From: turbo@bayour.com (Turbo Fredriksson) Date: Tue, 30 Jan 2018 21:23:42 +0000 Subject: [OpenAFS] convert 'vos dump' output to tar or zip? In-Reply-To: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> References: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> Message-ID: <524464E6-E3E3-4E00-9B20-79CC6DA5D766@bayour.com> --Apple-Mail=_1948B374-BD58-4B7D-89DB-3ADB34D3FF9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30 Jan 2018, at 21:20, Todd Lewis wrote: > Has anybody a tool to convert "vos dump" output to a tar or zip = format? This is something I used when I used AFS. Haven=E2=80=99t in many years, = so not sure if it still works. https://github.com/FransUrbo/scripts/blob/master/backup_afs.sh#L183-L189 > Is the "vos dump" format usable by anything other than "vos = restore=E2=80=9D? Not that I know of. --Apple-Mail=_1948B374-BD58-4B7D-89DB-3ADB34D3FF9C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEphdGmyrrCM2SA0dijiNPsX3/o00FAlpw4l4ACgkQjiNPsX3/ o005kQ/+KMb7ZJxK6eAN/hmZ1DoUlHgZ3gl487F8PqRzn2ktDIViCW/S9qdiSdAU j0LVy0GYOtdHfAEcVFy1PdaeDXyVp5JDrU4lnargsWiSo8/AFO2ywcinTysbtPyk sbLUqhzRbZ1MdCweBFT9OALrRlUGq6ja+oA4jWiKzw9EKaVM8Kg8XEJfosN1JeZX X3g48t5zDmj2n/E6H3aSnElw0C3NzdoOq5fOddP8CLGMvwMmkDRqHNF0luWgQWas Il6iP/R6lCeGsu/4E7sF7DGrSesVCL1VjhUeSwCY2c6U123X2VCaB01pc5uY6FjA Z+K8klBfgshWzzEnsKwcHjkBxp3KMmg7iEkiS15RMH7OtNCw/MSphHKQbg/d0wTF VafcFn+39wVKE5Z+NeBwPueZfB7tUQPnxhzyHgWKz0Mj8byIIp1lIH3UfQkZcWzd CLKpbBblff0PouF6BbEinKqtrAJd5NJLrcwSHtDQRgRV0ZU7oFTAygTvRmQvQ09z CTo2HnINgC7W016TeM7NPw4gKRDSRUuAelzwSsxFJ/d4fNRVcVyz3stdi4r2BP0R SparWiXlEo2W92ZnvgY1t6LgiBAJsc58KS1sBZIUUh/8ZS0IZIMqmFH8/Boa2hgQ PQRmnpx160OypoXvK65H9K5g7Vgo7qS6d7CGIgBZ1uquyP4pOSM= =9sDN -----END PGP SIGNATURE----- --Apple-Mail=_1948B374-BD58-4B7D-89DB-3ADB34D3FF9C-- From mmeffie@sinenomine.net Tue Jan 30 21:35:46 2018 From: mmeffie@sinenomine.net (Michael Meffie) Date: Tue, 30 Jan 2018 16:35:46 -0500 Subject: [OpenAFS] convert 'vos dump' output to tar or zip? In-Reply-To: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> References: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> Message-ID: <20180130163546.41f79462c6883df0bec9aa88@sinenomine.net> On Tue, 30 Jan 2018 16:20:03 -0500 Todd Lewis wrote: > Has anybody a tool to convert "vos dump" output to a tar or zip format? > > Is the "vos dump" format usable by anything other than "vos restore"? The 'restorevol' command can extract the files/directories to a local file system, but the acls are not preserved. The CMU dumpscan libraries and utilities can do many interesting things with dump streams. https://github.com/openafs-contrib/cmu-dumpscan (mirror) -- Michael Meffie From kula@tproa.net Tue Jan 30 21:44:12 2018 From: kula@tproa.net (Thomas Kula) Date: Tue, 30 Jan 2018 16:44:12 -0500 Subject: [OpenAFS] convert 'vos dump' output to tar or zip? In-Reply-To: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> References: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> Message-ID: <20180130214411.q2y6epg4gurvwotp@keymaster.tproa.net> On Tue, Jan 30, 2018 at 04:20:03PM -0500, Todd Lewis wrote: > Has anybody a tool to convert "vos dump" output to a tar or zip format? > > Is the "vos dump" format usable by anything other than "vos restore"? > *Ages* ago I used 'afsdump_extract' from http://grand.central.org/dl/software/dumpscan/ to pull files out of an AFS dump. But it just extracts to a local filesystem, no conversion. And I have no idea if the dump format has changed since 2006. I've also used http://docs.openafs.org/Reference/1/restorevol.html before, but, again, it just unpacks a dump file to local disk. That said, the AFS dump format isn't *too* hard to decipher. The hardest part, actually, is the AFS directory file format. https://kula.tproa.net/talks/afskbpw2009/kula-afs-dumps-2009.pdf is from when I last really was playing around with AFS dumps in any solid way other than doing regular backups. -- Thomas L. Kula | kula@tproa.net | http://kula.tproa.net/ From jaltman@auristor.com Tue Jan 30 22:07:04 2018 From: jaltman@auristor.com (Jeffrey Altman) Date: Tue, 30 Jan 2018 17:07:04 -0500 Subject: [OpenAFS] convert 'vos dump' output to tar or zip? In-Reply-To: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> References: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> Message-ID: <3b5d84cd-1cad-d6cc-5101-6c9acb1d7d43@auristor.com> This is a cryptographically signed message in MIME format. --------------ms020403000901080401070809 Content-Type: multipart/mixed; boundary="------------44E232B0A436F1D08AFE9026" Content-Language: en-US This is a multi-part message in MIME format. --------------44E232B0A436F1D08AFE9026 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Todd, Its been a while ... On 1/30/2018 4:20 PM, Todd Lewis wrote: > Has anybody a tool to convert "vos dump" output to a tar or zip format?= To the best of my knowledge there is not such a tool. Part of the reason a tool doesn't exist is that there would not be a lossless conversion from dump to either tar or zip. Assuming that the dump contains the full contents of a volume (not an incremental) it would be possible to transfer the directory tree, file data, and symlinks. However, mount points and AFS specific metadata including ACLs, policy bits, etc. would be lost. > Is the "vos dump" format usable by anything other than "vos restore"? Yes. dumpscan and restorevol can process dump files. Teradactyl's TiBS backup system can I believe import AFS dumps and restore to non-AFS file systems. There have also been several uncompleted projects that permit dumpfiles to be mounted as if they were ISOs on Linux and Windows. Perhaps it would be useful if you could discuss the end goal of the conversion. For example, you might describe the problem as: UNC is shutting down its cell and we have 20+ years of volume dumps as backups. We would like to be able to access the contents of these backups without deploying a new cell. Sincerely, Jeffrey Altman --------------44E232B0A436F1D08AFE9026 Content-Type: text/x-vcard; charset=utf-8; name="jaltman.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jaltman.vcf" begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St= ates email;internet:jaltman@auristor.com title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman= =3D0D=3D0A=3D Skype: jeffrey.e.altman=3D0D=3D0A=3D =09 url:https://www.auristor.com/ version:2.1 end:vcard --------------44E232B0A436F1D08AFE9026-- --------------ms020403000901080401070809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIIwggXpMIIE0aADAgECAhBAAV7gPRitcrlGsJTzkwjvMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE3MTAwMzAzMTczM1oXDTE4MTEwMzAzMTczM1owgYUxLTArBgNVBAsMJFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQGF1cmlzdG9yLmNvbTEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBh dXJpc3Rvci5jb20xLzAtBgoJkiaJk/IsZAEBEx9BMDE0MjdFMDAwMDAxNUVFMDNEMTg3QTAw MDA0QUE1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqqJC89ZA1DSS7t/Ug8Dd BQv5nBDumInWtFvHwVCORitVCvlkX4SfqKpERATq0eHOSc0zEz1PUjhAT8lgbNj8Bs92pL9t DW/VHHpq11w06rCEmZJNxgErAIvMpRuAhGrzvBpQBLj8nDArHWw+5nRn/KnK7ZO81LEEj4TG w0PEKGSa0aFA+JdRTJ6BZSDP2o/8AHx+Bw4JgW8VppAe4IuY/F+JoYtyQDL+fm1YMnFMtf1A 6IvlGXD7gMksPRbVIfD+QpHZbQvNXZAVVDaCWZuWQq46Vl4lSlkmW9yMlGddvFGl2zSMK7ny f0kbWJLw9lZxXDegY0/ciJPACPsyBwuyLwIDAQABo4ICnTCCApkwDgYDVR0PAQH/BAQDAgWg MIGEBggrBgEFBQcBAQR4MHYwMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJjaWFsLm9jc3Au aWRlbnRydXN0LmNvbTBCBggrBgEFBQcwAoY2aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0 LmNvbS9jZXJ0cy90cnVzdGlkY2FhMTIucDdjMB8GA1UdIwQYMBaAFKRz2u9pNYp1zKAZewgy +GuJ5ELsMAkGA1UdEwQCMAAwggEsBgNVHSAEggEjMIIBHzCCARsGC2CGSAGG+S8ABgsBMIIB CjBKBggrBgEFBQcCARY+aHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0 ZXMvcG9saWN5L3RzL2luZGV4Lmh0bWwwgbsGCCsGAQUFBwICMIGuGoGrVGhpcyBUcnVzdElE IENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdpdGggCklkZW5U cnVzdCdzIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2Vj dXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEUG A1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL3Ry dXN0aWRjYWExMi5jcmwwHwYDVR0RBBgwFoEUamFsdG1hbkBhdXJpc3Rvci5jb20wHQYDVR0O BBYEFNefZrPaqPUvaS6V6kAmHDwFhoDiMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDANBgkqhkiG9w0BAQsFAAOCAQEAKlssrfOJ5+WwHyhFSeSsioN0qpg2QDX/uvodF38JbquO 1U0my0j3Cc/bwk48++bjzp0Fvk/Kkcmss5/6zzJMjr9rf12QCQfKkbO9nMm8Bg6IP3pYgk0W /F1h3ZQF3OgBn3zZoOd3f1a6dF6z12MqKA/2g5GKrQFxkdzTGrNw6ISE9uY8ysvc3i2N2kas HNi5Etk7StZ1jvFX5sQMIeNdlF+z+BU/AyT7NoBS4gCH+ggF+DG7fAYywvy42Lfu8p6kopKT 5JZpYce1cNjnOaDhzhgeR+oXxoDbekF27JinXHQSKjBxhujcZu5leAkpctFpZxnIKZJZUBiu 31Nm7xYaijCCBpEwggR5oAMCAQICEQD53lZ/yU0Md3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVz dCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAyMTgyMjI1MTlaFw0yMzAyMTgyMjI1MTla MDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQg Q0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQl a3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZoCx3wef1kwC4pQQV2XHk+AKR+7uMvnOC Iw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDTQoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7 krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO1HS2Mfk9LnINeyzjxiXU/iENK07YvjBO xbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdX saieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQABo4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0w ezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEcG CCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1l cmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C5yZUyI42djAPBgNV HRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMwggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUF BwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3Bv bGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFz IGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENl cnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29t L2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlo dHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC9jb21tZXJjaWFscm9vdGNhMS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNV HQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJKoZIhvcNAQELBQADggIBAA3hgq7S+/Tr Yxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBbPGWvzdkmbSgYgXo8GxuAon9+HLIjNv68 BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/twQJeRfxHg3I+0Sfwp5xs10YF0Robhrs CRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrTA6045zQTKGzb370whliPLFo+hNL6XzEt y5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCmKCPIVPq/+9GqggGvtakM5K3VXNc9VtKP U9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7yE03nh2jLV7XAkcqad9vS4EB4hKjFFsm cwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6mYkzqrPigPazF2rgYw3lp0B1gSzCRj+j RtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR 8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCmunLMtaZ2vSai7du/VKrg64GGZNAKerEB evjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q/0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJ K32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UE ChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU85MI 7zANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTgwMTMwMjIwNzA0WjAvBgkqhkiG9w0BCQQxIgQgfPCU5zTgH8BnDqN/L3qJ 2FWTxFSHF0zWGR9HSBZ4+2IwXQYJKwYBBAGCNxAEMVAwTjA6MQswCQYDVQQGEwJVUzESMBAG A1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMgIQQAFe4D0YrXK5RrCU 85MI7zBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5U cnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTICEEABXuA9GK1yuUawlPOTCO8wbAYJKoZI hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQBZmhMVuiBiIDI1XX1vmxGzKUvRxo08F7L5y9G/0xZhIeZOvJjMrfGl 0YXlj8SjWA3LTjCKik3DqNzbyQHMKDW5CLdOyDqQZEsHEjHiWUewkcg5Ai1q31+Uaqw5N2Pq oHLcaAiFuW/C0UeHb7UuC+dAlAWliGKwvVYE7AMhNW97/MfH2zBCZWUU6rm+VR8Yg/GXzTEJ TlntcNUx2pp3NGcYclbXXnyu0Nl5nvSH6oUo8mrmYqyB4onmvvlvUBHZeW/1U9+HWtLBQx4L gdY0XDqbE5pFT8wExL1+fwrjlQCFQlCWRi0uepTiQwCFY5ffEzglaroBFbTTWe7IOdqvl+br AAAAAAAA --------------ms020403000901080401070809-- From utoddl@email.unc.edu Wed Jan 31 00:20:54 2018 From: utoddl@email.unc.edu (Todd Lewis) Date: Tue, 30 Jan 2018 19:20:54 -0500 Subject: [OpenAFS] convert 'vos dump' output to tar or zip? In-Reply-To: <3b5d84cd-1cad-d6cc-5101-6c9acb1d7d43@auristor.com> References: <2cdd438f-7705-b43f-6fa9-735a4de2f30d@email.unc.edu> <3b5d84cd-1cad-d6cc-5101-6c9acb1d7d43@auristor.com> Message-ID: Thanks, Jeffrey. In fact we are in the process (arguably have been for at least a decade, but there seems to be actual momentum this time) of shuttering our AFS service. The particular use case I have in mind is a web page users can hit (a) to retrieve a copy of their AFS home volumes as either a tar balls or zip files, and (b) to confirm that they no longer need said volumes so that we can begin the deprovisioning process on them. My hope is that by making this part self-service we can focus our limited staff resources on dealing with departmental and other organizations' volumes. Most of our home volumes are relatively small by today's standards. There are ways to traverse a volume without dropping through mount points ('up' can do it, and I've probably got some perl code that does it too), feeding the list of found files to tar and/or zip, and that's probably what I'll end up using. But if somebody had a blob of vos-dump-handling code lying around I'd feel silly not to have asked. I understand that we'd be losing mount points, ACLs, etc. but for this case that's alright. Fortunately, we'll probably avoid the need to delve into a pile of vos dump backups. On a personal note, I'll really miss AFS. It's one of my personal top three technologies I've gotten to work with in my 34+ years here. The way data governance and service delivery are managed by location in a long-lived file system instead of tied directly to fleets of always aging application hosts is something we never clearly communicated to management. I can't tell you how many hours I've spent in meetings discussing problems that simply would not have existed had AFS been in play. The community has been extremely helpful and professional, and I'm grateful for the opportunities I've had due to their efforts. For years -- decades actually -- we've joked about C-level executives who've declared AFS dead yet didn't last as long here as AFS. Lately I've been saying that when I retire I'm going to take AFS with me. Maybe I'll stand up a cell at home on some Raspberry Pies and make good on that. Alas, life, unlike this email, is short... On 01/30/2018 05:07 PM, Jeffrey Altman wrote: > Hi Todd, > > Its been a while ... > > On 1/30/2018 4:20 PM, Todd Lewis wrote: >> Has anybody a tool to convert "vos dump" output to a tar or zip format? > To the best of my knowledge there is not such a tool. Part of the > reason a tool doesn't exist is that there would not be a lossless > conversion from dump to either tar or zip. > > Assuming that the dump contains the full contents of a volume (not an > incremental) it would be possible to transfer the directory tree, file > data, and symlinks. However, mount points and AFS specific metadata > including ACLs, policy bits, etc. would be lost. > >> Is the "vos dump" format usable by anything other than "vos restore"? > Yes. dumpscan and restorevol can process dump files. > > Teradactyl's TiBS backup system can I believe import AFS dumps and > restore to non-AFS file systems. > > There have also been several uncompleted projects that permit dumpfiles > to be mounted as if they were ISOs on Linux and Windows. > > Perhaps it would be useful if you could discuss the end goal of the > conversion. For example, you might describe the problem as: > > UNC is shutting down its cell and we have 20+ years of volume > dumps as backups. We would like to be able to access the > contents of these backups without deploying a new cell. > > Sincerely, > > Jeffrey Altman > > > From kfiresmith@gmail.com Wed Jan 31 14:41:22 2018 From: kfiresmith@gmail.com (Kodiak Firesmith) Date: Wed, 31 Jan 2018 09:41:22 -0500 Subject: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up Message-ID: --f40304398e6c243945056413791e Content-Type: text/plain; charset="UTF-8" Folks, re-sending this because the first try never hit the list - perhaps mail with attachments are silently dropped or held for manual moderation? I'd originally attached an image of the stack trace. I'll host it and reply to this with a URL link in case that would also result in a drop or moderation. Anyhow: In testing the new RHEL 7.5 beta, we've discovered that hosts using AFS fail to boot after the upgrade, with Openafs 1.6.22.1 installed. We are wondering if some of the non-guaranteed kernel ABIs that OpenAFS uses might have changed with the latest kernel provided in RHEL 7. I've attached a picture of the trace. Anyone else kicking the tires on the new RHEL yet? Thanks! --f40304398e6c243945056413791e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Folks, re-sending this because the first try never hit the= list - perhaps mail with attachments are silently dropped or held for manu= al moderation?=C2=A0 I'd originally attached an image of the stack trac= e.=C2=A0 I'll host it and reply to this with a=C2=A0 URL link in case t= hat would also result in a drop or moderation.



Anyhow:=C2=A0=C2=A0

In testin= g the new RHEL 7.5 beta, we've discovered that hosts using AFS fail to = boot after the upgrade, with Openafs 1.6.22.1 installed.=C2=A0=C2=A0
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.= 8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial"><= br>
We are wondering if some of the non-guaranteed kernel ABIs that Op= enAFS uses might have changed with the latest kernel provided in RHEL 7.=C2= =A0=C2=A0

I've attached a picture of the trace.
Anyone else kicking the tires on the new RHEL yet?

=
= Thanks!

--f40304398e6c243945056413791e-- From kfiresmith@gmail.com Wed Jan 31 14:43:59 2018 From: kfiresmith@gmail.com (Kodiak Firesmith) Date: Wed, 31 Jan 2018 09:43:59 -0500 Subject: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up In-Reply-To: References: Message-ID: --089e0822381c8411e3056413820a Content-Type: text/plain; charset="UTF-8" https://photos.app.goo.gl/WgPsSUCLK5ojxIuH3 On Wed, Jan 31, 2018 at 9:41 AM, Kodiak Firesmith wrote: > Folks, re-sending this because the first try never hit the list - perhaps > mail with attachments are silently dropped or held for manual moderation? > I'd originally attached an image of the stack trace. I'll host it and > reply to this with a URL link in case that would also result in a drop or > moderation. > > > > Anyhow: > > In testing the new RHEL 7.5 beta, we've discovered that hosts using AFS > fail to boot after the upgrade, with Openafs 1.6.22.1 installed. > > We are wondering if some of the non-guaranteed kernel ABIs that OpenAFS > uses might have changed with the latest kernel provided in RHEL 7. > > I've attached a picture of the trace. > > Anyone else kicking the tires on the new RHEL yet? > > Thanks! > > --089e0822381c8411e3056413820a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Jan 31, 2018 a= t 9:41 AM, Kodiak Firesmith <kfiresmith@gmail.com> wrote:=
Folks, re-sending this = because the first try never hit the list - perhaps mail with attachments ar= e silently dropped or held for manual moderation?=C2=A0 I'd originally = attached an image of the stack trace.=C2=A0 I'll host it and reply to t= his with a=C2=A0 URL link in case that would also result in a drop or moder= ation.



Anyhow:=C2=A0=C2=A0=

In testing the new RHEL 7.5 beta, we've disco= vered that hosts using AFS fail to boot after the upgrade, with Openafs 1.6= .22.1 installed.=C2=A0=C2=A0

We are wondering if some of the= non-guaranteed kernel ABIs that OpenAFS uses might have changed with the l= atest kernel provided in RHEL 7.=C2=A0=C2=A0

I've attach= ed a picture of the trace.

Anyone else kicking the tires on = the new RHEL yet?

Thanks!


--089e0822381c8411e3056413820a-- From fmsv030@uni-hamburg.de Thu Jan 11 11:47:43 2018 From: fmsv030@uni-hamburg.de (Gaja Sophie Peters) Date: Thu, 11 Jan 2018 12:47:43 +0100 Subject: [OpenAFS] OpenAFS 1.8.0 beta 4 available In-Reply-To: <20180106022235.GC25484@kduck.kaduk.org> References: <20180106022235.GC25484@kduck.kaduk.org> Message-ID: <5bdee158-9d48-1a16-b901-77667f9a851a@uni-hamburg.de> Am 06.01.2018 um 03:22 schrieb Benjamin Kaduk: > The OpenAFS Guardians are happy to announce the availability of the fourth > prerelease candidate of OpenAFS 1.8.0. What better opportunity to test the new release, than when the DKMS of the old release from jessie (1.6.9-2+deb8u6) AND from jessie-backports (1.6.18.2-1~bpo8+1) fails to build on the new kernel with the "Meltdown"-fixes (which for Debian-Jessie is 3.16.0-5-amd64)... I created packages in a way similar to what I wrote in https://lists.openafs.org/pipermail/openafs-info/2016-December/041997.html only that I did it all on a Debian Jessie system, instead of Ubuntu 14.04. So far everything works fine, the DKMS-module was built successfully and the AFS-client seems completely usable. Greetings, Gaja Peters P.S. In case anybody can (or wants to) make use of these packages, I copied them to the AFS in the publicly accessible directory /afs/math.uni-hamburg.de/public/fmsv030/openafs-1.8.0~pre4-1_amd64_Debian-Jessie