[OpenAFS] Re: OpenAFS Windows client will not map drives
Jeffrey Altman
jaltman@secure-endpoints.com
Mon, 06 Mar 2006 11:22:42 -0500
This is a cryptographically signed message in MIME format.
--------------ms030709000909050003020303
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sean:
do the following:
start filemon and turn on Clock Time and Show Milliseconds
configure filemon to only watch Network drives
start filemon capturing
at the command line execute:
fs trace -on
dir \\afs\all\
dir \\afs\sph.umich.edu
fs trace -dump
stop capturing in filemon and save the output.
Place the \windows\temp\afsd.log and filemon files somewhere in AFS
or on the web where they can be accessed.
Thanks
Sean Caron wrote:
> OK
>
> i look: only things checked on loopback adaptor AFS are Client for
> Microsoft Networks,
> TCP/IP. Novell client is not bound to loopback adaptor in any way.
>
> (at this point i have to say, it was my error earlier in stating that
> the AFS client broke the
> Novell client. it just gives this impression because for some reason, it
> seems as if it is
> necessary to wait around 2-3 minutes at the login prompt before trying
> to log in or else
> you will get the "Tree or server cannot be found" error. if you wait, it
> will eventually work.
> but why? i could see this being something that would really confuse and
> irritate a user)
>
> so ok, let's proceed.
>
> i have the open afs client set up for monitoring with debugview and
> filemon. i follow the manual token-getting procedure:
>
> C:\> kinit -5 -V -d scaron
> Kerberos 5 is ready
> Password for scaron@SPH.UMICH.EDU <mailto:scaron@SPH.UMICH.EDU>:
> Authenticated to Kerberos v5
>
> C:\> aklog -d
> Authenticating to cell sph.umich.edu <http://sph.umich.edu>.
> Getting v5 tickets: afs/sph.umich.edu@SPH.UMICH.EDU
> <mailto:afs/sph.umich.edu@SPH.UMICH.EDU>
> Getting v5 tickets: afs@SPH.UMICH.EDU <mailto:afs@SPH.UMICH.EDU>
> pioctl temp != 0: 0x66543200
> About to resolve name scaron@SPH.UMICH.EDU <mailto:scaron@SPH.UMICH.EDU>
> to id
> Id 32766
> Set username to scaron@SPH.UMICH.EDU <mailto:scaron@SPH.UMICH.EDU>
> Getting tokens.
>
> C:\> tokens
>
> Tokens held by the Cache Manager:
>
> User scaron@SPH.UMICH.EDU <mailto:scaron@SPH.UMICH.EDU>'s tokens for
> afs@sph.umich.edu <mailto:afs@sph.umich.edu> [Expires Mar 06 19:15]
> pioctl temp != 0: 0x66543218
>
>
> so it looks like, as i stated earlier, there is no problem in actually
> obtaining the tokens from
> the server. running nbtstat -n, we obtain, on the loopback adaptor, the
> results:
>
> SPH-2002-0892 <00> UNIQUE Registered
> SPH <00> UNIQUE Registered
> AFS <20> UNIQUE Registered
>
> on the real LAN connection, we have the results:
>
> SPH-2002-0892 <00> UNIQUE Registered
> SPH <00> UNIQUE Registered
>
> so the AFS service is uniquely registered on the loopback adaptor, as it
> should be.
>
> so now i try and hit up an AFS share using the command: Start->Run
> \\afs\sph.umich.edu
>
> i wait maybe, 15-20 seconds and get the message:
>
>
> "This file does not have a program associated with it for performing
> this action. Create an association in the Folder Options control panel"
>
> if i try to set up an actual drive mapping with NET USE, e.g.
>
> NET USE \\afs.sph.umich.edu\user\s\scaron h:
>
> i get the same "System error 67: Network name cannot be found" error.
>
> SO:
>
> i don't see anything that looks glaringly erroneous popping up in debugview.
>
> looking in filemonon, i see that explorer.exe is pulling off READ/QUERY
> INFORMATION/CLOSE calls to the paths that i want to access correctly.
> that is, the result code is SUCCESS. this is the case for
> \\afs\sph.umich.edu, \\afs\sph.umich.edu\user\s\scaron, etc. so i would
> guess that is a good sign.
>
> i also am seeing that afsd_service.exe keeps trying to find a file,
> AFSDHOOK.DLL, that it is not finding. this is unsurprising, since the
> file does not exist on the filesystem, nor does it seem to be included
> in the installer (i searched through the MSI file looking for it). could
> the lack of this file be the cause of the "no program associated
> with..." errors?
>
> this is feeling more like a problem with how openafs and windows
> interact together, rather than a problem with just openafs itself. i
> think openafs is mostly acting correctly. it just seems like windows
> doesnt know how to deal with it properly.
>
> any suggestions on how to further proceed?
>
> thanks,
>
> sean caron
>
>
>
>
> On 3/3/06, *Jeffrey Altman* <jaltman@columbia.edu
> <mailto:jaltman@columbia.edu>> wrote:
>
> Sean:
>
> On the Loopback adapter, unbind everything but:
>
> * Client for Microsoft Networks
> * Internet Protocol
>
> Using the GUIs is not going to help you here so I advise that you stop
> trying to use them.
>
> Please read the Debugging OpenAFS section of the release notes that
> I pointed you at earlier. Turn on PIOCTL debugging, Trace Logging,
> and obtain a copy of the SysInternals DbgView and FileMon tools.
> After setting everything up as described in the Release Notes execute
> the following commands from the command line:
>
> * kinit <user@REALM>
> * aklog -d
> * tokens
>
> Now if you have any form of connectivity with the AFS SMB Server you
> will have obtained tokens and been able to list them. Otherwise, you
> will have received another copy of the Network Name Not Found error.
>
> At that point, you need to use "nbtstat -n" to list all of the
> registered network names. The following line should appear once
> and only once on the Loopback Adapter:
>
> AFS <20> UNIQUE Registered
>
> There should be no other names on that adapter with type <20>. If
> there are, you will lose. If AFS <20> appears on any other adapter,
> you will lose.
>
> If you have any machine on your network that is adverting the name
> AFS <20>, you will lose.
>
> Jeffrey Altman
>
>
>
> Sean Caron wrote:
> > Thanks for the suggestions so far. What I am doing is: I have a couple
> > of spare machines in my office that I am
> > testing various configurations of the OpenAFS client on, so I can try
> > all sorts of funky things and not have to
> > worry about messing up a machine that someone is actually using. I set
> > one up to test the behaviour of the
> > client with the loopback adapter on, as so:
> >
> > (1) Wiped a machine a did a fresh load of our disk image (XP, Novell
> > client, etc). Computer name is SPH-2002-0196.
> > I saw some old post on the Internet implying that dashes in the
> hostname
> > might cause problems with the AFS
> > client, but they dated from 2002 or 2003, so I'm assuming it doesn't
> > matter these days. I think I mentioned earlier
> > that I tried a system with a boring alphanumeric only name (SPHAFSTEST)
> > and it didn't help anything.
> >
> > (reboot)
> >
> > (2) Installed MIT Kerberos v3.0.0 with all default settings on;
> krb5.ini
> > has been properly customized for our site.
> > Kerberos is set to start automatically when Windows starts (as would
> > make sense). (side note: MIT Kerberos seems to
> > work fine in and of itself. It gladly will go authenticate and get
> > tokens). I did this as an administrator; normal users wouldn't
> > normally be allowed to install software given the way we have security
> > set up on our workstation disk image.
> >
> > (reboot)
> >
> > (3) Installed OpenAFS Windows Client v1.4.0 (as an administrator) WITH
> > the loopback adaptor installed this time. Use our
> > CellServDB file that actually includes our site. Set AFS cell name to
> > "sph.umich.edu <http://sph.umich.edu> < http://sph.umich.edu>".
> Everything else is set per
> > installation
> > defaults (AFS crypt security = on, AFS freelance client = on, DNS
> > cellserver search = on, start afscreds on login = on, auto
> > initialize afscreds = on, renew drivemaps = on, ip change detection =
> > on, quiet = on). Installer completes successfully.
> >
> > (reboot)
> >
> > (4) Now my test workstation is back online, sitting at the login
> prompt.
> > I try to login to the Novell network (client version 4.91, by
> > the way). Now it doesn't work! "The tree or server cannot be found.
> > Choose a different tree or server....". OK. Let's log in as
> > "Workstation only". Did the Novell client get bound up in the loopback
> > adapter or something? Can this be dealt with? I know very
> > little about Novell (I am a new hire at SPH, and mostly a UNIX guy).
> >
> > (5) So I log in to the local machine only and get the AFS Client
> "Obtain
> > New AFS tokens" dialog box. Enter username and password
> > and authenticate to cell "sph.umich.edu <http://sph.umich.edu> <
> http://sph.umich.edu>". Wait a
> > minute or two, and the tickets show up in the MIT Kerberos Network
> Identity
> > Manager. So at least authentication and ticketing is all good.
> >
> > (6) Testing: Start->Run. "\\afs\all". I get the message: "This file
> does
> > not have a program associated with it for performing this action.
> > Create an association in the Folder Options control panel".
> >
> > OK.
> >
> > Testing: Start->Run. "\\afs\sph.umich.edu". Same message.
> >
> > Testing: Start->Run. "\\afs\sph.umich.edu\user\s\scaron". Wait a
> second
> > or two... same message.
> >
> > Testing: Start->Run. "cmd". From command prompt: "net use
> > \\afs\sph.umich.edu\user\s\scaron h:". We get the message: "The
> > network name cannot be found (system error 67)".
> >
> > Testing: Click "Drive Letters" tab in AFS client. It sits for a while
> > (30 secs - 1 minute). Click "Add". Select "Drive F", AFS path
> > "\afs\sph.umich.edu\user\s\scaron", submount "homes". I get the error:
> >
> > "AFS was unable to map the network drive to the specified path in AFS.
> > Check to make sure the drive letter is not currently in use"
> > "Error 0x00000043"
> >
> > (i was thinking about it and it hit me that 43 hex = 67 decimal so i
> > guess NETWORK NAME CANNOT BE FOUND is the issue here)
> >
> > (7) Check network properties. We have two connections installed.
> >
> > One is called AFS and is bound to the loopback adaptor. Uses items:
> > Novell client for Windows, Client for Microsoft networks, Remote
> > management, Novell workstation manager, Novell distributed print
> > services, TCP/IP
> >
> > The other is the default Local Area Network connection. Uses items:
> > Novell client for Windows, Client for Microsoft networks, QoS
> > packet scheduler, Remote management, Novell workstation manager, Novell
> > distributed print services, TCP/IP. Windows firewall is
> > on. We use DHCP to get all network card parameters & DNS server
> > information. TCP/IP filtering is off. NetBIOS is set to "Use NetBIOS
> > setting from DHCP server. If static IP address is used or DHCP server
> > does not provide NetBIOS setting, enable NetBIOS over TCP/IP"
> >
> > I see that we don't actually have a NetBIOS protocol installed by
> > default on our load. Let's do it manually for now.
> >
> > (8) Add protocol: NWLink IPX/SPX/NetBIOS Compatible Transport Protocol
> > (this is the only NetBIOS protocol available in the list).
> > Install it.
> >
> > (reboot)
> >
> > (9) So we're back at the login prompt and you still can't log in to
> > Novell. We get the same "The tree or server cannot be found..."
> message.
> > Let's login to local workstation only again and proceed. Once again
> I am
> > able to successfully log in, authenticate to sph.umich.edu
> <http://sph.umich.edu>
> > < http://sph.umich.edu>, and
> > obtain tokens.
> >
> > (10) Try the same testing suite again:
> >
> > Testing: Start->Run. "\\afs\all". I get the message: "This file
> does not
> > have a program associated with it for performing this action.
> > Create an association in the Folder Options control panel".
> >
> > Testing: Start->Run. "\\afs\sph.umich.edu". Same message.
> >
> > Testing: Start->Run. "\\afs\sph.umich.edu\user\s\scaron". Same message.
> >
> > Testing: Start->Run. "cmd". From command prompt: "net use
> > \\afs\sph.umich.edu\user\s\scaron h:". We get the message: "The
> > network name cannot be found (system error 67)".
> >
> > Testing: Click "Drive Letters" tab in AFS client. It comes up instantly
> > this time around. Click "Add". Select "Drive F", AFS path
> > "\afs\sph.umich.edu\user\s\scarno", submount "homes". I again get
> the error:
> >
> > "AFS was unable to map the network drive to the specified path in AFS.
> > Check to make sure the drive letter is not currently in use"
> > "Error 0x00000043"
> >
> > That didn't seem to help anything.
> >
> > (11) Go to Network Connections->Advanced Settings. In "adapters and
> > bindings" I move the AFS (loopback) connection to the top of
> > the pile. Go to Provider Order tab and move OpenAFSDaemon to the very
> > top of the heap (it was at the very bottom).
> >
> > (reboot)
> >
> > (12) I'm not even going to try and log into the Novell network this
> time
> > around. Log in to local machine only and run my series of test
> > commands again. Same results as above.
> >
> > (13) It was suggested that I perhaps unbind NWLink IPX/SPX/NetBIOS
> > Compatible Transport Protocol from the Client for Microsoft
> > Networks. Go back into Network->Advanced Settings and do that.
> While I'm
> > at it, I see that TCP/IP has become unbound from the
> > Novell client. So I bind that back up while I'm there.
> >
> > (reboot)
> >
> > (14) Why not try and log into Novell this boot around? I still get the
> > "Tree or server cannot be found" error. Let's login to the workstation
> > only and proceed again.
> >
> > (15) Run my little suite of test commands again. Same results as above
> > (no change).
> >
> > This is about where I stand now. I've tried some various other things:
> > Hard setting "NetBIOS over TCP/IP" to ON instead of taking settings
> > based on DHCP values, manually entering DNS servers, turning off
> Windows
> > firewall, etc. All seem to have no effect. I've repeated all this
> > for both the cases of loopback adaptor installed, and loopback adaptor
> > not installed, basically, with (roughly) the same effects. Some of
> > the errors I got without the loopback adaptor were a little
> different (I
> > remember getting a system error 53 a couple of times, among other
> > things).
> >
> > I tried to be as exhaustive as possible in compiling my little report
> > here; I hope it isn't entirely too much wasted reading and writing for
> > myself and all of you out there on the list. I'm really hoping to be
> > able to get this to work, or, failing that, at least be able to go
> to my
> > supervisor and say without a doubt that "the AFS client for Windows
> will
> > not work with [our] Novell installation [because]...", so I want
> > to be sure that I pretty much left no stone unturned.
> >
> > Thanks, everyone, for all the help thus far. Please don't hesitate to
> > ask me about anything if you feel that you might need more knowledge
> > about my system environment to be able to offer any useful
> suggestions.
> >
> > Regards,
> >
> >
> > Sean Caron
> >
> > Associate Systems Administrator
> > University of Michigan School of Public Health
> > 1-734-763-4206
> > scaron@umich.edu <mailto:scaron@umich.edu> <mailto:scaron@umich.edu
> <mailto:scaron@umich.edu>>
> >
> >
> > On 3/3/06, *Rodney M Dyer* < rmdyer@uncc.edu
> <mailto:rmdyer@uncc.edu> <mailto: rmdyer@uncc.edu
> <mailto:rmdyer@uncc.edu>>> wrote:
> >
> > At 12:12 PM 3/3/2006, Jeffrey Altman wrote:
> > >I have heard of other organizations having problems with both
> > Novell and
> > >OpenAFS clients on the same machines. I have not had access
> to such a
> > >configuration to be able to debug it.
> >
> > Just a note. We run the Novell client without issues with OpenAFS
> > and the
> > loopback adapter. We DO NOT however use the Novell GINA
> > module. After we
> > install the Novell client, we replace the nwgina.dll back to
> > msgina.dll. We also place the afslogon.dll authenticator first
> in the
> > providers list.
> >
> > Rodney
> >
> > Rodney M. Dyer
> > Windows Systems Programmer
> > Mosaic Computing Group
> > William States Lee College of Engineering
> > University of North Carolina at Charlotte
> > Email: rmdyer@uncc.edu <mailto:rmdyer@uncc.edu> <mailto:
> rmdyer@uncc.edu <mailto:rmdyer@uncc.edu>>
> > Web: http://www.coe.uncc.edu/~rmdyer
> <http://www.coe.uncc.edu/%7Ermdyer>
> > Phone: (704)687-3518
> > Help Desk Line: (704)687-3150
> > FAX: (704)687-2352
> > Office: Cameron Applied Research Center, Room 232
> >
> >
>
>
>
--------------ms030709000909050003020303
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC
AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3
WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT
SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k
cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/
bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM
S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm
RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX
wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD
6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs
dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L
IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G
y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB
BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w
NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE
KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI
hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa
bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE
APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q
IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj
qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25
XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG
A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK
i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt
9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/
MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z
dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD
VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv
bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5
WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk
LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2
vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9
A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw
EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0
ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R
BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ
Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN
d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG
A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDYxNjIyNDJaMCMGCSqG
SIb3DQEJBDEWBBTqFvCHihPaC4pJW6lbA96SQNc9SDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC
AQARPLDeqFMP/sh5zG+Xkmdlql5ulhW3eeWN5SwN1Bc1k8Di5Hi39mHKrdg7sPQPGn76IrRb
IA9n/nRi3FqVEa6Fr9WOGJn/jE3m48z9xF26jP7OtPMtUftk5FK4wari82N948e0SvFGUtdq
a4VIQ6xBgg8NaqPtBfMPYnUmx5hY3Tx1OoS9DG6QrWcfH+D6OCtYtwam3lZV2SU7J7KzAaUg
oo7MfPeu/NXd7cZI34w+vwBsiKgLUiGekjqcUH5WqgMi0jzE19EWK7BLMGf7sm/Tb4advuc5
QgB2+3K18wltr4Sgo/0BL0b4fASneJiuOS0oXXazBwUbOQxYRYfjrb6nAAAAAAAA
--------------ms030709000909050003020303--