[Probably OT] Strange loss of ability to do SSL (through curl)

[Ben Rubinstein]

Thanks Mike and Peter, that's indeed got me to the next stage.

Using this technique I can get curl to work correctly (and by using 
env/printenv as the command, I can see the differences in the environment) - 
as you suspected, the difference is in PATH.

Now the next question (which brings it back on topic): given that I can now 
get curl-through-shell to work this way; how can I get LC's native URL 
functions to work?

TIA,

Ben

On 21/01/2015 18:05, Mike Bonner wrote:
> yeah, same thing as source, I forgot you could . it
>
> On Wed, Jan 21, 2015 at 10:06 AM, Peter Haworth <pete at lcsql.com> wrote:
>
>> Courtesy of Dariusz Miedzianogora a while back on this list:
>>
>>
>> "You could try the following command in the shell call:
>>
>> . ~/.profile;<your unix command>
>>
>> The first dot (.) executes the next file. The ~ (tilde) is a shortcut to
>> the home directory of the user. Since .profile is a shell script that is
>> executed when the user logs in, this will rerun the .profile script in the
>> local shell, and you should get the updated path. The semi-colon means that
>> the command continues, so you can then execute your shell command in the
>> process instance (and thus the shell instance) that you just refreshed. "
>>
>>
>> On Jan 21, 2015 8:42 AM, "Mike Bonner" <bonnmike at gmail.com> wrote:
>>
>>> You might check to see the environment variables from the command line,
>> and
>>> via lc shell, and do a comparison.  If I recall correctly, lc shell
>>> environment and the environment you get in a terminal or console can
>>> differ.  If the lc shell is using bash, and you know which files are
>>> processed when a terminal session starts, you can "source" them.  Source
>> is
>>> a built in command that processes the file you give it. So if you have a
>>> file .bashrc in your home directory that has the required env variables
>> set
>>> up you could get shell("source /path/to/my/home/.bashrc; the rest of your
>>> commands here" )
>>>
>>> If you can figure out what env variables are missing, but required for
>> what
>>> you want to do, you can probably include them at the top of your curl ssl
>>> script file
>>>
>>> On Wed, Jan 21, 2015 at 8:39 AM, Bob Sneidar <
>> bobsneidar at iotecdigital.com>
>>> wrote:
>>>
>>>> Use the sudo command. Sudo allows an administrator account to
>> masquerade
>>>> as root. You will need to provide the current login password when you
>> do
>>>> this. I have successfully put the password as a second line in a
>> terminal
>>>> command. The current login must be an administrator.
>>>>
>>>> Bob S
>>>>
>>>>
>>>>> On Jan 21, 2015, at 07:17 , Ben Rubinstein <benr_mc at cogapp.com>
>> wrote:
>>>>>
>>>>> Bob,
>>>>>
>>>>> Thanks for replying - I suspect you're right as to the immediate
>> cause
>>>> and where something has changed (it might just be about a new
>>> certificate,
>>>> for example).
>>>>>
>>>>> However, my real question is why it works in terminal but not using
>> LC
>>>> "shell"; although calling the same service does work via LC "shell" on
>> my
>>>> dev machine (including as a standalone).
>>>>>
>>>>> Where can one affect the context in which a shell command is
>> executing?
>>>>>
>>>>> thanks,
>>>>>
>>>>> Ben
>>>>>
>>>>> On 20/01/2015 19:12, Bob Sneidar wrote:
>>>>>> I suspect whatever system you are connecting to has modified in some
>>>> way how it encrypts data using SSL. Sounds crazy, but Microsoft
>> recently
>>>> did something to their TLS in their cloud offerings that summarily
>>>> prevented an entire series of Konica brand copiers from sending email
>>>> through Exchange Online. Other series Konicas were fine, and other
>>>> manufacturers didn’t seem to have a problem either. I was the only one
>>>> saying Microsoft had made changes to their TLS. No one would listen,
>>> citing
>>>> all the other copiers that still worked.
>>>>>>
>>>>>> Finally Konica released a bulletin telling us to install special
>>>> firmware and make some changes in the security settings on the affected
>>>> machines. What settings you ask? Why, the TLS settings of course!
>>>>>>
>>>>>> Bob S
>>>>>>
>>>>>>
>>>>>>> On Jan 20, 2015, at 10:59 , Ben Rubinstein <benr_mc at cogapp.com>
>>> wrote:
>>>>>>>
>>>>>>> An app built in LC, sitting on an old box (PPC Mac Mini running
>>>> 10.4.11) has for several years happily been running a few times a day
>> to
>>>> perform a batch job involving retrieve some data from a remote system,
>>>> processing it, and pushing a report to a new location.
>>>>>>>
>>>>>>> Recently, it's not been updating correctly, and investigation has
>>>> shown that the cause is a failure to retrieve the remote data.
>>>>>>>
>>>>>>> The remote system (a third-party SaaS product) has a REST
>> interface,
>>>> accessed with simple basic authentication over HTTPS.  I'm not aware
>> that
>>>> anything has changed in their API recently.
>>>>>>>
>>>>>>> When I first wrote this app, I found that LC didn't correctly deal
>>>> with the SSL portion (I forget the details); so I recoded it to use the
>>>> shell function to invoke curl to retrieve each element.
>>>>>>>
>>>>>>> This has worked fine for a long time.   But now the shell command
>> is
>>>> returning code 35, which according to man curl is:
>>>>>>>   35     SSL connect error. The SSL handshaking failed.
>>>>>>>
>>>>>>> So the weird thing is:
>>>>>>> - if I run this app on my dev machine (Intel Mac running 10.8.5),
>> it
>>>> works fine, happily invoking curl and getting the result
>>>>>>> - if I run the curl command in Terminal on the target machine, it
>>>> works fine and retrieves the data
>>>>>>> - if I create a shell script to run the curl command on the target
>>>> machine, and invoke that shell script in Terminal, it works fine and
>>>> retrieves the data
>>>>>>> - if I modify the app to use 'shell' to run that shell script,
>>> instead
>>>> of calling curl directly, it fails with code 35 again.
>>>>>>>
>>>>>>> So curl, and shell, are happy on that machine; but using shell in
>> an
>>>> LC app to either invoke curl directly, or run a batch script which
>>> invokes
>>>> curl, makes SSL fail.
>>>>>>>
>>>>>>> I've marked this possibly OT because I don't think it's necessarily
>>> an
>>>> LC problem.  I get the same result with a version of the app built in
>>> 2011
>>>> from LC 4.6.4 as with one built now with LC 6.5.2.  But then again, I'm
>>> not
>>>> aware that anything has changed on the machine where this runs.
>>>>>>>
>>>>>>> Something must have changed; my guess is that it is something in
>> the
>>>> setup of the remote service.  But the nature of that change doesn't
>>> disturb
>>>> curl or shell running under Terminal on my target machine; nor when
>>> invoked
>>>> from LC on my dev machine.
>>>>>>>
>>>>>>> I'm guessing it must be something to do with the environment in
>> which
>>>> the shell command operates when invoked from LC, as opposed to
>> launching
>>> a
>>>> terminal window.  This goes considerably outside my knowledge area, so
>>> I'm
>>>> appealing for suggestions as to where to investigate...
>>>>>>>
>>>>>>> TIA
>>>>>>>
>>>>>>> Ben