[lug] job market

[Valentina Kibuyaga]

Hello Linux Users Group

Just wondering and looking for relocation opportunities...

What is the job market in Boulder, Co?

Are you aware of anyone hiring with a database background with some work in AWS?

Thanks, Valentina
________________________________
From: LUG <lug-bounces at lug.boulder.co.us> on behalf of duboulder <blug-mail at duboulder.com>
Sent: Friday, October 11, 2019 12:27 PM
To: Boulder \(Colorado\) Linux Users Group -- General Mailing List <lug at lug.boulder.co.us>
Subject: Re: [lug] FTPS + SSL parameters question...

Assuming your tests are connecting to the same ip/port/dns name as the app and you aren't having a source ip access problem, I wonder if you have the same jvm/jvm setup for the app vs tests.

Does the ftps server give any details about the app connect failure? Or does the java class provide any details about the failure?

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 11, 2019 10:03 AM, Bear Giles <bgiles at coyotesong.com> wrote:

This is a stretch but I'm running out of ideas.

We're trying to connect to an FTPS server in implicit mode. The server requires the data connection to use the same SSL parameters as the control connection as an authentication mechanism.

Java isn't happy but I can force it by seeding the undocumented SSLSession cache.

Bottom line is that my integration tests pass - I'm connecting to the (Filezilla) server...

... but my actual application fails. I've verified that everything is lined up and (AFAIK) it's creating the request with the correct SSL Parameters but something, somehow, is changing them in flight.

I've checked with coworkers - we have a packet monitor but it doesn't do deep packet inspection. We don't have a network proxy. I can't think of anything else that would modify the SSL Parameters.

Any ideas, esp. something that would appear in a Java environment?

Unfortunately we can't ask the customer to change their server settings. We can't try switching to mutual authentication (using SSL keypairs) either.

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20191011/ac44171e/attachment.html>