[OpenAFS] OpenAFS access at login time on MacOS
Jeffrey E Altman
jaltman@auristor.com
Sat, 13 May 2023 11:44:11 -0400
This is a cryptographically signed message in MIME format.
--------------ms090702020307050307090002
Content-Type: multipart/alternative;
boundary="------------K8I4spbZqmiXGqggpSBn2Rrj"
--------------K8I4spbZqmiXGqggpSBn2Rrj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 5/11/2023 6:20 AM, Richard Feltstykket (richard@unixboxen.net) wrote:
> Hello Everyone,
>
> Perhaps it is widely known already, but I just wanted to share a
> process that I have worked out to get a kerberos ticket and an afs
> token at login time on MacOS. It seems to work fine for MacOS Ventura
> and Monterey; I have not tested on other versions.
Thanks for posting.
>
> My cell takes FOREVER to log in for some reason, but after aklog
> completes in the background, I have a token and can access volumes in
> the cell.
Negative DNS lookups impose an unnecessary time delay.
Assuming the name of your domain example.net is also the name of your
cell and Kerberos realm (in upper case), and assuming the following
hostnames for your kdc and afsdb servers
kdc1.example.net
afsdb1.example.net
create the following DNS entries
_kerberos.example.net. IN TXT "EXAMPLE.NET"
_kerberos._afs.example.net. IN TXT "EXAMPLE.NET"
_kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net.
_kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net.
_kerberos._http.example.net. IN SRV 0 0 0 .
_kerberos._kkdcp.example.net. IN SRV 0 0 0 .
_afs3-vlserver._udp.example.net. IN SRV 10 0 7003 afsdb1.example.net.
_afs3-prserver._udp.example.net. IN SRV 10 0 7002 afsdb1.example.net.
If you are using the AFS backup service:
_afs3-budbserver._udp.example.net. IN SRV 10 0 7021 afsdb1.example.net.
If you are not using the AFS backup service:
_afs3-budbserver._udp.example.net. IN SRV 0 0 0 .
If there are more than one KDC or AFSDB server, then create one
_kerberos* SRV record for each KDC and one _afs3-* entry for each AFSDB
server.
Note that the hostname specified in a SRV record must not be a CNAME; it
must be A or AAAA records. For the _afs3-* SRV records for an OpenAFS
cell which does not support IPv6 the specified hostname should not have
a AAAA record. The AuriStorFS cache managers and Linux kernel afs
(kafs) clients will attempt to contact the location servers via IPv6 if
there is a AAAA record specified.
A SRV record whose hostname is "." indicates that the service is
unavailable.
The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens and
rxkad_k5 tokens. An OpenAFS cell does not support yfs-rxgk but aklog
doesn't know that until it is explicitly told by the Kerberos realm that
there is no yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET service principal.
This requires that GSS-KRB5 be able to quickly resolve the Kerberos
realm for the name "_afs.unixboxen.net". The SRV record specified
above for _kerberos._afs.unixboxen.net is intended to speed up the
resolution of the hostname to realm mapping if the client is configured
to do so.
For rxkad_k5 tokens the resolution of which Kerberos realm to use is
performed by enumerating the hostnames of the location servers,
performing an A/AAAA DNS query to obtain the IP addresses, then
performing a PTR record lookup on the IP addresses. For example
afsdb1.example.net A -> 192.0.2.23
129.0.2.23 PTR -> host.example.net
_kerberos.host.example.net TXT -> "EXAMPLE.NET"
_kerberos.example.net TXT -> "EXAMPLE.NET" (queried if the
_kerberos.host.example.net entry is not present)
If there are more than one location service address, then the one that
is used for resolution of the Kerberos realm can appear to be random
because whichever is first in the list will be used.
Issuing a "kinit user@EXAMPLE.NET" against your realm took a little more
than six seconds to perform the DNS lookups for the kdc on a macOS
Ventura 13.4 system. It then took approximately 180ms to receive the
expected principal unknown response to the AS-REQ. I cannot measure
the time to perform the aklog operations because I cannot obtain a TGT
to test with.
The time for the AuriStorFS v2021.05-28 cache manager on macOS 13.4 to
"ls -l /afs/example.net" anonymously was
* 470ms to resolve the location service via DNS (3 RPCs)
* 330ms to resolve the location of the "root.cell" volume (2 RPCs +
reachability test)
* 850ms for the fileserver response to the first RPC including the
fileserver->client callback service TellMeAboutYourself queries (3
RPCs + reachability tests)
* 600ms to read the contents of the root directory and obtain status
info for each entry (3 RPCs)
The ICMP ping rtt from my test system to the location server averages
115ms.
If the vlserver and fileserver connections were authenticated using
rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test for each RX
connection would be replaced by a CHALLENGE|RESPONSE exchange. If the
cache manage to fileserver connection was authenticated using yfs-rxgk,
then the fileserver TellMeAboutYourself query to the cache manager would
not be performed.
I suspect you can reduce some of the time by adding the DNS records that
are not present in your domain. You can observe the DNS, Kerberos and
AFS queries using wireshark https://www.wireshark.org/download.html.
Start a capture and set a filter rule of "dns or rx or kerberos or icmp
or icmpv6".
Feel free to reply privately if you wish to discuss details of your
actual network configuration.
Jeffrey Altman
--------------K8I4spbZqmiXGqggpSBn2Rrj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 5/11/2023 6:20 AM, Richard
Feltstykket (<a class="moz-txt-link-abbreviated" href="mailto:richard@unixboxen.net">richard@unixboxen.net</a>) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net">Hello
Everyone,
<br>
<br>
Perhaps it is widely known already, but I just wanted to share a
process that I have worked out to get a kerberos ticket and an afs
token at login time on MacOS. It seems to work fine for MacOS
Ventura and Monterey; I have not tested on other versions.
<br>
</blockquote>
Thanks for posting.<br>
<blockquote type="cite"
cite="mid:20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net">
<br>
My cell takes FOREVER to log in for some reason, but after aklog
completes in the background, I have a token and can access volumes
in the cell.
<br>
</blockquote>
<p>Negative DNS lookups impose an unnecessary time delay.</p>
<p>Assuming the name of your domain example.net is also the name of
your cell and Kerberos realm (in upper case), and assuming the
following hostnames for your kdc and afsdb servers</p>
<blockquote>
<p>kdc1.example.net</p>
<p>afsdb1.example.net<br>
</p>
</blockquote>
<p>create the following DNS entries</p>
<blockquote>
<p>_kerberos.example.net. IN TXT "EXAMPLE.NET"</p>
<p>_kerberos._afs.example.net. IN TXT "EXAMPLE.NET"<br>
</p>
<p>_kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net.</p>
<p>_kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net.</p>
<p>_kerberos._http.example.net. IN SRV 0 0 0 .</p>
<p>_kerberos._kkdcp.example.net. IN SRV 0 0 0 .</p>
<p>_afs3-vlserver._udp.example.net. IN SRV 10 0 7003
afsdb1.example.net.</p>
<p>_afs3-prserver._udp.example.net. IN SRV 10 0 7002
afsdb1.example.net.</p>
</blockquote>
<p>If you are using the AFS backup service:<br>
</p>
<blockquote>
<p>_afs3-budbserver._udp.example.net. IN SRV 10 0 7021
afsdb1.example.net.</p>
</blockquote>
<p>If you are not using the AFS backup service:</p>
<blockquote>
<p>_afs3-budbserver._udp.example.net. IN SRV 0 0 0 .</p>
</blockquote>
<p>If there are more than one KDC or AFSDB server, then create one
_kerberos* SRV record for each KDC and one _afs3-* entry for each
AFSDB server.</p>
<p>Note that the hostname specified in a SRV record must not be a
CNAME; it must be A or AAAA records. For the _afs3-* SRV
records for an OpenAFS cell which does not support IPv6 the
specified hostname should not have a AAAA record. The AuriStorFS
cache managers and Linux kernel afs (kafs) clients will attempt to
contact the location servers via IPv6 if there is a AAAA record
specified.</p>
<p>A SRV record whose hostname is "." indicates that the service is
unavailable.<br>
</p>
<p>The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens
and rxkad_k5 tokens. An OpenAFS cell does not support yfs-rxgk
but aklog doesn't know that until it is explicitly told by the
Kerberos realm that there is no
<a class="moz-txt-link-abbreviated" href="mailto:yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET">yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET</a> service principal.
This requires that GSS-KRB5 be able to quickly resolve the
Kerberos realm for the name "_afs.unixboxen.net". The SRV record
specified above for _kerberos._afs.unixboxen.net is intended to
speed up the resolution of the hostname to realm mapping if the
client is configured to do so. <br>
</p>
<p>For rxkad_k5 tokens the resolution of which Kerberos realm to use
is performed by enumerating the hostnames of the location servers,
performing an A/AAAA DNS query to obtain the IP addresses, then
performing a PTR record lookup on the IP addresses. For example </p>
<blockquote>
<p>afsdb1.example.net A -> 192.0.2.23</p>
<p>129.0.2.23 PTR -> host.example.net</p>
<p>_kerberos.host.example.net TXT -> "EXAMPLE.NET"<br>
</p>
<p>_kerberos.example.net TXT -> "EXAMPLE.NET" (queried if the
_kerberos.host.example.net entry is not present)</p>
</blockquote>
<p>If there are more than one location service address, then the one
that is used for resolution of the Kerberos realm can appear to be
random because whichever is first in the list will be used.</p>
<p>Issuing a "kinit <a class="moz-txt-link-abbreviated" href="mailto:user@EXAMPLE.NET">user@EXAMPLE.NET</a>" against your realm took a
little more than six seconds to perform the DNS lookups for the
kdc on a macOS Ventura 13.4 system. It then took approximately
180ms to receive the expected principal unknown response to the
AS-REQ. I cannot measure the time to perform the aklog
operations because I cannot obtain a TGT to test with.</p>
<p>The time for the AuriStorFS v2021.05-28 cache manager on macOS
13.4 to "ls -l /afs/example.net" anonymously was</p>
<ul>
<li>470ms to resolve the location service via DNS (3 RPCs)<br>
</li>
<li>330ms to resolve the location of the "root.cell" volume (2
RPCs + reachability test)<br>
</li>
<li>850ms for the fileserver response to the first RPC including
the fileserver->client callback service TellMeAboutYourself
queries (3 RPCs + reachability tests)<br>
</li>
<li>600ms to read the contents of the root directory and obtain
status info for each entry (3 RPCs)<br>
</li>
</ul>
<p>The ICMP ping rtt from my test system to the location server
averages 115ms. <br>
</p>
<p>If the vlserver and fileserver connections were authenticated
using rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test
for each RX connection would be replaced by a CHALLENGE|RESPONSE
exchange. If the cache manage to fileserver connection was
authenticated using yfs-rxgk, then the fileserver
TellMeAboutYourself query to the cache manager would not be
performed.<br>
</p>
<p>I suspect you can reduce some of the time by adding the DNS
records that are not present in your domain. You can observe the
DNS, Kerberos and AFS queries using wireshark
<a class="moz-txt-link-freetext" href="https://www.wireshark.org/download.html">https://www.wireshark.org/download.html</a>. Start a capture and set
a filter rule of "dns or rx or kerberos or icmp or icmpv6".</p>
<p>Feel free to reply privately if you wish to discuss details of
your actual network configuration.</p>
<p>Jeffrey Altman</p>
<br>
</body>
</html>
--------------K8I4spbZqmiXGqggpSBn2Rrj--
--------------ms090702020307050307090002
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
DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz
MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew
MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt
YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3
xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN
fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI
EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg
9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG
IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr
BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF
BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx
My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG
A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov
L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt
bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g
aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj
YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp
ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v
dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY
MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s
gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV
eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c
WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq
utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo
Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt
a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA
AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe
Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L
wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/
15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn
o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0
3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2
VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG
CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu
dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t
L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C
5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0
dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl
eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg
YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy
dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v
Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0
dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy
bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG
CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2
bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s
0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u
6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88
QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4
Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu
db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb
rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d
UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn
p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA
MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG
A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg
ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIzMDUxMzE1
NDQxMVowLwYJKoZIhvcNAQkEMSIEIORYbRDygElCsrpzspsfKuJOVVuRbnx/UtXL9ghCoVb4
MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX
MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ
AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy
dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAXaSd
CwEV8p+jeuA0rgSO2uB69mE9Y6VWZT7ZCQnRvA7srd2yIgMO48gi9r+gRBDUiaPpNZbl7Vav
dWDTiUcz8084Gn06zNkS4nsT2I8/sstFjlWhQFjIRMYYEyAiBDlj0oluvvQA+rMUmS34sTip
LGfhwxwvOkVlQ3dT/Kaeld4A4eEhlPvv5QX4pJHjd3ObQWjORGUUZxqj/jhPqKLzqzuf1Euo
Qv5FQmvwoNq8QHaDjd0agnIOhTp88vzN2lE5DOiJixnEyNWVGG5fwwcOF3k3trJQkkl/ieO4
vBuhAhO7CjH+UF+PWlr8HJavybktlG3uM4lbkt9iwGunDKMMrQAAAAAAAA==
--------------ms090702020307050307090002--