X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.22.2a (ClamAV engine v0.102.2) X-Junk-Score: 0 [] X-KAS-Score: 0 [] From: "Markus Ruggiero (rucotec)" Received: from miniserver.rucotec.ch ([213.189.151.242] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 26041960 for webobjects-dev@wocommunity.org; Fri, 18 Jun 2021 12:49:16 +0200 Received-SPF: none receiver=post.selbstdenker.com; client-ip=213.189.151.242; envelope-from=markus.ruggiero@rucotec.ch Received: from localhost (localhost [127.0.0.1]) by miniserver.rucotec.ch (Postfix) with ESMTP id AA9C52AD67C1 for ; Fri, 18 Jun 2021 12:48:55 +0200 (CEST) Received: from miniserver.rucotec.ch ([127.0.0.1]) by localhost (miniserver.rucotec.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArEm5TSGqB4r for ; Fri, 18 Jun 2021 12:48:52 +0200 (CEST) Received: from [192.168.56.49] (unknown [192.168.56.49]) by miniserver.rucotec.ch (Postfix) with ESMTPSA id 3C9AB2AD67B0 for ; Fri, 18 Jun 2021 12:48:52 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_70D50081-6962-4CF8-B25B-3E77262BA1A0"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: [WO-DEV] Deployment issue on Catalina "You don't have permission to access this resource" Date: Fri, 18 Jun 2021 12:48:51 +0200 References: To: WebObjects & WOnder Development In-Reply-To: Message-Id: <427B16DD-F037-42B2-A797-647248968F41@rucotec.ch> X-Mailer: Apple Mail (2.3608.120.23.2.7) --Apple-Mail=_70D50081-6962-4CF8-B25B-3E77262BA1A0 Content-Type: multipart/alternative; boundary="Apple-Mail=_71E97C21-15A2-44F9-8C9C-237ED18B2F80" --Apple-Mail=_71E97C21-15A2-44F9-8C9C-237ED18B2F80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Jesse, yeah, I tried all. All files are w:r including = /Library/WebObjects/Configuration/* where SiteConfig.xml lives. = JavaMonitor is writing the SiteConfig.xml, wotaskd uses it and it is = readable for anything Apache. Apache running under _www or, as I just now tried running it under my = own uid, makes no difference. The error_log shows this line: [Fri Jun 18 10:39:44.022934 2021] [authz_core:error] [pid 50274] [client = 127.0.0.1:60139] AH01630: client denied by server configuration: /apps, = referer: = http://localhost:3333/cgi-bin/WebObjects/JavaMonitor.woa/wo/6tRZCAqtsrsCiS= rXLUPUMg/0.0.1.0 = I tried with cgi-bin as well as apps. For me this indicates something in WOAdaptor not being right. When I = google this error everyone is pointing to Apache config where in some = places Require all allowed is needed. That is there and Apache can serve = static filesystem based resources.=20 As the error points to /apps as the resource that is not accessible this = again points to WOAdaptor. /apps is NOT a file system path (no = block in http.conf) but is part of the adaptor URL (set in = JavaMonitor as http://woapps/apps/WebObjects = ). Seems that WOAdaptor does not properly = take over and then of course Apache would try to access this = non-existing path. This brings me to the next question: how do I debug WOAdaptor? Or am I = going nuts? Something else: I compared all the LoadModule directives in httpd.conf = with those on the customer deployment and made sure there weren=E2=80=99t = modules excluded. Nothing helped. Next is probably to virtualise the = client deployment machine, strip it down to the bare minimum and run it = as a test deployment server inside VMWare. Maybe last resort.... ---markus--- > On 17 Jun 2021, at 17:07, Jesse Tayler = wrote: >=20 > Well, gosh, it just has to be apache and the OS =E2=80=94 run down the = list of suspects >=20 > "client denied by server configuration" is reported so that=E2=80=99s = basically the OS saying you can=E2=80=99t read =E2=80=94 I think? >=20 > I can=E2=80=99t read your rules, but since apache doesn=E2=80=99t seem = to barf did you check user and OS level stuff carefully? >=20 > - the user that is running apache? > - the actual folder and parent folder settings? > - read those folders as that user from the command line? >=20 > Other random tests regarding OS level file permissions? >=20 > I=E2=80=99m no expert here, but I=E2=80=99m pretty sure those files = gotta be 755 and it seems like the apache log is reporting a filesystem = level permission error=E2=80=A6? >=20 >=20 >=20 >=20 >> On Jun 17, 2021, at 10:59 AM, Markus Ruggiero (rucotec) = > = wrote: >>=20 >> This is a new setup. Up to now I have had a dedicated deployment = machine that works. As this is for a customer I do not want to touch it. >>=20 >> We have a weird problem that only shows when more than one instance = of the same app is running. To be able to debug and analyze this I = thought I=E2=80=99d configure my dev machine so that I can deploy to it = easily without disturbing anything productive. >>=20 >> Yes, of course mod_webobjects is loaded. This is the full = wo_apache.config: >>=20 >> LoadModule WebObjects_module = /Users/Shared/Developer/Libraries/Wonder/ApacheWOAdaptor/Apache2.4/macOS/m= od_WebObjects.so >> WebObjectsAlias /apps/WebObjects >> WebObjectsConfig http://woapps:1085 10 >>=20 >> all the other nice stuff in there is commented and not active. >>=20 >> If on a command line I type >> apachectl -F >>=20 >> I get a whole list of known directives and there are many WO related = ons. Where else would Apache get those if not through mod_webobjects? = This indicates that the module is properly loaded. >>=20 >>=20 >>> On 17 Jun 2021, at 16:44, Jesse Tayler = > = wrote: >>>=20 >>> Sounds like apache, are you sure things like mod_webobjects are = loaded and those base things? >>>=20 >>> I can=E2=80=99t read apache rules=E2=80=A6sorry! They are all just = random characters to me=E2=80=A6I guess the questions is what=E2=80=99s = changed or is this a new setup giving you a hard time? >>>=20 >>>> On Jun 17, 2021, at 10:40 AM, Markus Ruggiero (rucotec) = > = wrote: >>>>=20 >>>> Probably missing something so basic that I simply do not see it. = Must be too hot outside (33 Celsius) and no aircon in the office (31 = Celsius).=20 >>>> Hope someone can point me in the right direction. >>>>=20 >>>> Deployment setup on my dev machine (MBpro, macOS Catalina, JRE 15). = Apache installed via homebrew (Apache/2.4.46 (Unix)), Apple's Apache not = in use >>>>=20 >>>> Apache configured with various virtual hosts, resolved through = /etc/hosts. This all works, Apache serves static resources from these = hosts. >>>>=20 >>>> JavaMonitor runs, wotaskd runs, Apache loads WOAdaptor by including = wo_apache.conf >>>> apachectl -F knows about WOAdaptor, so I assume it is properly = loaded >>>>=20 >>>> wo_apache.conf has this line: >>>> WebObjectsAlias /apps/WebObjects=20 >>>>=20 >>>> The Apache config file http.conf has this line >>>> # ScriptAliasMatch ^/cgi-bin/((?!(?i:webobjects)).*$) = "/usr/local/var/www/CGI-Executables/$1" >>>> ScriptAliasMatch ^/apps/((?!(?i:webobjects)).*$) = "/usr/local/var/www/CGI-Executables/$1" >>>>=20 >>>> (tried both variants, with cgi-bin and the one with apps) >>>>=20 >>>> In WOMonitor this is the URL to the adaptor: >>>> http://woapps/apps/WebObjects >>>> (woapps being one of my virtual hosts) >>>>=20 >>>> When I try to access an installed app the browser reports an error >>>> "You don't have permission to access this resource=E2=80=9D >>>>=20 >>>> and Apache puts a message into the error log file: >>>> [Thu Jun 17 13:43:57.329921 2021] [authz_core:error] [pid 42093] = [client 127.0.0.1:64420] AH01630: client denied by server configuration: = /apps >>>>=20 >>>> /apps is not a directory but the first part of the WO URL and thus = should go to the WOAdaptor. Has the ScriptAliasMatch (see above) = anything to do with this? >>>>=20 >>>> Thanks for any help >>>> ---markus--- >>>>=20 >>>>=20 >>>> Markus Ruggiero >>>>=20 >>>> rucotec GmbH web https://rucotec.ch = >>>> Steinenvorstadt 79 email markus.ruggiero@rucotec.ch = >>>> 4051 Basel / Switzerland mobile +41 79 508 4701 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> Markus Ruggiero >>=20 >> rucotec GmbH web https://rucotec.ch = >> Steinenvorstadt 79 email markus.ruggiero@rucotec.ch = >> 4051 Basel / Switzerland mobile +41 79 508 4701 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 Markus Ruggiero rucotec GmbH web https://rucotec.ch Steinenvorstadt 79 email markus.ruggiero@rucotec.ch 4051 Basel / Switzerland mobile +41 79 508 4701 --Apple-Mail=_71E97C21-15A2-44F9-8C9C-237ED18B2F80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Jesse, yeah, I tried all. All files are w:r including = /Library/WebObjects/Configuration/* where SiteConfig.xml lives. = JavaMonitor is writing the SiteConfig.xml, wotaskd uses it and it is = readable for anything Apache.

Apache running under _www or, as I just now tried running it = under my own uid, makes no difference. The error_log shows this = line:
[Fri Jun 18 10:39:44.022934 2021] = [authz_core:error] [pid 50274] [client 127.0.0.1:60139] AH01630: client = denied by server configuration: /apps, referer: http://localhost:3333/cgi-bin/WebObjects/JavaMonitor.woa/wo/6tR= ZCAqtsrsCiSrXLUPUMg/0.0.1.0

I tried with cgi-bin as well as = apps.

For me = this indicates something in WOAdaptor not being right. When I google = this error everyone is pointing to Apache config where in some places = Require all allowed is needed. That is there and Apache can serve static = filesystem based resources. 
As the error = points to /apps as the resource that is not accessible this again points = to WOAdaptor. /apps is NOT a file system path (no <Directory> = block in http.conf) but is part of the adaptor URL (set in JavaMonitor = as http://woapps/apps/WebObjects). Seems that WOAdaptor does = not properly take over and then of course Apache would try to access = this non-existing path.

This brings me to the next question: how do I debug = WOAdaptor? Or am I going nuts?

Something else: I compared all the = LoadModule directives in httpd.conf with those on the customer = deployment and made sure there weren=E2=80=99t modules excluded. Nothing = helped. Next is probably to virtualise the client deployment machine, = strip it down to the bare minimum and run it as a test deployment server = inside VMWare. Maybe last resort....

---markus---

On 17 = Jun 2021, at 17:07, Jesse Tayler <webobjects-dev@wocommunity.org> wrote:

Well, gosh, it just = has to be apache and the OS =E2=80=94 run down the list of suspects

"client denied by server = configuration" is reported so that=E2=80=99s basically the OS saying you = can=E2=80=99t read =E2=80=94 I think?

I can=E2=80=99t read your rules, but = since apache doesn=E2=80=99t seem to barf did you check user and OS = level stuff carefully?

- the user that is running apache?
- the = actual folder and parent folder settings?
- read = those folders as that user from the command line?
Other random tests regarding OS level = file permissions?

I=E2=80=99m no expert here, but I=E2=80=99m pretty sure those = files gotta be 755 and it seems like the apache log is reporting a = filesystem level permission error=E2=80=A6?




On Jun 17, 2021, at 10:59 AM, Markus Ruggiero = (rucotec) <webobjects-dev@wocommunity.org> wrote:

This is a new setup. = Up to now I have had a dedicated deployment machine that works. As this = is for a customer I do not want to touch it.

We have a weird problem that only shows = when more than one instance of the same app is running. To be able to = debug and analyze this I thought I=E2=80=99d configure my dev machine so = that I can deploy to it easily without disturbing anything = productive.

Yes,= of course mod_webobjects is loaded. This is the full = wo_apache.config:

LoadModule WebObjects_module = /Users/Shared/Developer/Libraries/Wonder/ApacheWOAdaptor/Apache2.4/macOS/m= od_WebObjects.so
WebObjectsAlias = /apps/WebObjects
WebObjectsConfig http://woapps:1085 10

all the other nice stuff in there is = commented and not active.

If on a command line I type
apachectl = -F

I get a = whole list of known directives and there are many WO related ons. Where = else would Apache get those if not through mod_webobjects? This = indicates that the module is properly loaded.


On 17 Jun 2021, at 16:44, Jesse = Tayler <webobjects-dev@wocommunity.org> wrote:

Sounds like apache, = are you sure things like mod_webobjects are loaded and those base = things?

I can=E2=80=99= t read apache rules=E2=80=A6sorry! They are all just random characters = to me=E2=80=A6I guess the questions is what=E2=80=99s changed or is this = a new setup giving you a hard time?

On Jun = 17, 2021, at 10:40 AM, Markus Ruggiero (rucotec) <webobjects-dev@wocommunity.org> wrote:

Probably missing = something so basic that I simply do not see it. Must be too hot outside = (33 Celsius) and no aircon in the office (31 Celsius). 
Hope someone can point me in the right direction.

Deployment setup on my = dev machine (MBpro, macOS Catalina, JRE 15). Apache installed via = homebrew (Apache/2.4.46 (Unix)), Apple's Apache not in use

Apache configured with = various virtual hosts, resolved through /etc/hosts. This all works, = Apache serves static resources from these hosts.

JavaMonitor runs, wotaskd runs, Apache = loads WOAdaptor by including wo_apache.conf
apachectl -F knows about = WOAdaptor, so I assume it is properly loaded

wo_apache.conf has this = line:
WebObjectsAlias   = /apps/WebObjects 

The Apache config file http.conf has this line
# ScriptAliasMatch = ^/cgi-bin/((?!(?i:webobjects)).*$) = "/usr/local/var/www/CGI-Executables/$1"
ScriptAliasMatch ^/apps/((?!(?i:webobjects)).*$) = "/usr/local/var/www/CGI-Executables/$1"

(tried both variants, with cgi-bin and = the one with apps)

In WOMonitor this is the URL to the adaptor:
http://woapps/apps/WebObjects
(woapps = being one of my virtual hosts)

When I try to = access an installed app the browser reports an error
"You don't have permission to access this = resource=E2=80=9D

and Apache puts a message into the error log file:
[Thu Jun 17 13:43:57.329921 2021] = [authz_core:error] [pid 42093] [client 127.0.0.1:64420] AH01630: client = denied by server configuration: /apps

/apps is not a directory but the first = part of the WO URL and thus should go to the WOAdaptor. Has the = ScriptAliasMatch (see above) anything to do with this?

Thanks for any = help
---markus---


Markus = Ruggiero

rucotec GmbH              =           web https://rucotec.ch
Steinenvorstadt 79          =       email markus.ruggiero@rucotec.ch
4051 Basel / = Switzerland         mobile +41 79 508 4701













Markus = Ruggiero

rucotec GmbH              =           web https://rucotec.ch
Steinenvorstadt 79          =       email markus.ruggiero@rucotec.ch
4051 Basel / = Switzerland         mobile +41 79 508 4701











Markus = Ruggiero


rucotec GmbH              =           web https://rucotec.ch
Steinenvorstadt 79          =       email markus.ruggiero@rucotec.ch
4051 Basel / = Switzerland         mobile +41 79 508 4701








= --Apple-Mail=_71E97C21-15A2-44F9-8C9C-237ED18B2F80-- --Apple-Mail=_70D50081-6962-4CF8-B25B-3E77262BA1A0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCzkw ggUhMIIECaADAgECAhBDXz2PBS4rcSTMoUCPbeA+MA0GCSqGSIb3DQEBCwUAMIGWMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYD VQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUyMjAwMDAwMFoXDTIyMDUyMTIzNTk1 OVowKzEpMCcGCSqGSIb3DQEJARYabWFya3VzLnJ1Z2dpZXJvQHJ1Y290ZWMuY2gwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIAEK8S00IWrMmIpBkw5CcIS9RfaNGWyJOxskmtuYoHWE4 +QYfOO5tlWt4O5F6bTYsRWp1PpLirrdLhQoYIFp0P5Mi0nsBjNVP0zR0jNpDZreNcLcP7wmuIkUY C0fzxFgnRieFFgaXFm5yf46rqAJMVry/uR/KqwvY1d2F2gOb4DmntPp7TJtDsVyWQDtB82Uep+EO 9j71phQuMUb5TyA4aOdSb6UfCev1RgEw8vXrTdf+1rLzRZvIR1syfsqcLVmIO9WSl9mTH7IlZQhx SmTLqSTvTLssRGprVK8dhJl0nDvFuKknUGNxwCwON1ojJdZPgUJi1K+VvkCqDlI61czNAgMBAAGj ggHTMIIBzzAfBgNVHSMEGDAWgBQJwPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUFRQz2DQf fM2xz9tI/Gy05p6XXc0wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYI KwYBBQUHAwQGCCsGAQUFBwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUH AgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwu c2VjdGlnby5jb20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNv bS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggr BgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIEabWFya3VzLnJ1Z2dp ZXJvQHJ1Y290ZWMuY2gwDQYJKoZIhvcNAQELBQADggEBACeso6Iombd/K2MXqk+u5cFNAi3kNRv5 t1WMA2YodqQxz/i/H9OxagG8Ukk5IcHgrikpy0dlOgJ9nOGEWJYrzZbLWZCMd7I8NQpT28vnkgKM 51tzAARg7mHu+SPKwvnDfYB8CFNSQ+Wlkq8wJHL9ALuTeGCRdnRmNtit8o/sRV25KoH6+0U2k08U TO5J+bzVendvcfygdf3bPp3+imRIlXJihwb2fg6OOMqVCnUFHKrdJULZ+SWSWNclriu5GbM1pKql d5dIrApf9M9b9XbY89XgHdFHA5bx7taL1Ie1msC23llmUVSYTHjNOqNrprgfKXvao1taAQvpDhzx BQXzO6YwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqGSIb3DQEBDAUAMIGIMQsw CQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAyjztlApB/975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXj So5MqXUfItMltrMaXqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQ PKA19xeWQcpGEGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ 79Khj1YBrf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se 3ed0PewDch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0j BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0A MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHYG CCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VTRVJU cnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADdF9d6HBA4kMjjsb0XMZHz tuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou74TZ/XTarHG8zdMSgaDrkVYzz 1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk 2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI +jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO 2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3 a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEG VqR1hiuQOZ1YL5ezMTX0ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niF hsM47qodx/PL+5jR87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6m SWE3Bn7i5ZgtwCLXgAIe5W8mybM2JzGCA8QwggPAAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhBDXz2PBS4rcSTMoUCPbeA+MA0GCWCGSAFlAwQCAQUAoIIB6TAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA2MTgxMDQ4NTFaMC8G CSqGSIb3DQEJBDEiBCC6iPHNuMmHjMAHIEy+Z7U4QKRCtWoVDSt08gJPbw19xjCBvAYJKwYBBAGC NxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3Rp Z28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBDXz2PBS4r cSTMoUCPbeA+MIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBM aW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIQQ189jwUuK3EkzKFAj23gPjANBgkqhkiG9w0BAQEFAASCAQB+iPd+5ool uDvJlTEwN57WCPRZYt1YCUDlBMYXI4uBZq7zzvBmbTMnJq/Xv74/aeUdao0RtPAxmdsUr4QFXXDO ywlIDP9ns94x7WRpxu7RJmx0d30m52/T0hve3LkEgJhXJ/fInsvbk5n4hky103Xpp0Mtqs5JiPdc YGut8dsOdq08UeDMhJaydPqSTjUAP693XQkpmPDBpc+FZJbv+N+nLtKJRol4fBh6fGFo8a5unox4 kl2JbsK1HlptFJljmv3JPXs5aLRNkqLqs0LF8kdmtoWRzcUybphLiGdMq5hER4fIQ1gkeQI7ZXVJ xkhviUx4KB3sK/i2N7LXWdr0IszXAAAAAAAA --Apple-Mail=_70D50081-6962-4CF8-B25B-3E77262BA1A0--