Lazarus Indy SSL IdHTTP - linux

I'm trying to get Indy to work with SSL and the IdHTTP component in Lazarus installed on Ubuntu 11. I know my code is right for the http post since if I remove the https and leave it as only http it works. So I figure it's the SSL and indy's components missing Linux libraries. For window's I was use to just including the two DLL's, libeay32.dll and ssleay32.dll and it worked fine.
But in linux it seems to be another story. The only code I have is the post code:
IdHttp1.Post('url', StringList, ReturnStreamList);
Like I said it works great without the https, but when I try SSL nothing happens at all. No error since I have try and except to catch but I'm not doing anything with the catching.
I do have OpenSSL installed, I also have the following installed through apt:
libcrypto++8
libcrypto++-dev
libssl-dev
libssl0.9.8
I went to /usr/lib and both the files libcrypto.so and libssl.so are there.
Any ideas what's missing to get SSL to work with Lazarus and Indy for IdHTTP post operations?
EDIT: Ok, after following advice below I have added the exception:
on E: EIdHTTPProtocolException do
showmessage(htp1.ResponseText);
This gives me the error Error creating SSL context.
EDIT2: I ran an strace and I have pasted the output areas where it open's the SSL libraries here:
http://pastebin.com/fL6tTSGg

This was so easy it ticks me off! ha ha
Seems I was using the wrong method for the SSL. I had to set TidSSLioHandlerSocketOpenSSL.SSLOptions.Method to sslvSSLv23, it was on sslvSSLv2.
Now everything works fine :)

Related

Plesk: Using nodejs results in an error "Cannot find module 'phusion_passenger/line_reader'

Having an issue with Plesk and nodejs-extension using phusion passenger.
My Plesk Version: Plesk Obsidian 18.0.31 Update #2
My OS: Ubuntu 18.04.5 LTS
Using nodejs 12.4.0 which is primarly installed via plesk.
I set up two domains. On both i run npm install via the plesk ui. Everything works and nothing results in an error, until I head to the domains, I got following error messages within development mode:
On domain 1:
Domain 1 error
On domain 2
Domain 2 error
Its a bit confusing since everything seems to work fine.
I have already tried to set an Environment variable in /etc/nginx/conf.d/phusion-passenger.conf:
passenger_env_var NODE_PATH /usr/share/passenger/node;
Reason is that in phusion passengers github somebody recommends this within an issue. And in /usr/share/passenger/node/phusion-passenger/ I found the line_reader.js.
But this doesn't solve the problem.
Thanks for helping me out
So I figured out, that the path-variables aren't correct for phusion to work. After editing them hard in the code everything works fine.
I am still not happy about this solution. So if anyone knows another option to solve this. please suggest.

puppet module install windows over http

So,
I used to install puppet module via http://forge.puppetlabs.com without any issues. But then all of a sudden I am getting an error 301 Moved Permanently when trying to install any modules.
I would run the following command
puppet module install --module_repository http://forge.puppetlabs.com puppetlabs-dism
Now this appears to fail.
I have used both 3.4.2 and 3.8.7 (updated thinking their was an issue with the version)
I also have a similar command for ubuntu which works fine, but this is without the module_repository parameter.
The reason for the --module_repository flag is to get around the ssl certificate issue not being valid.
So the question being, has this functionality been removed, or does anyone know how to get the ssl certificate to be valid.
The url is in the process of being changed to https://forge.puppet.com as explained in ticket FORGE-327. Try using the updated url and see if that works for you.
As for the ssl error, see the documentation here and look at the first bullet point. It describes the reason this is happening and solutions for it.

Virtualmin Installation

I had installed virtualmin on a RHEL system and a couple of very strange problems have cropped up.
Firstly, the Apache test page now says - powered by CentOS instead of RHEL. All the files and filesystems are intact therefore I am at a loss as to why it would report another version of linux altogether.
Secondly, my sudo access has been overwritten / removed after installation. It just comes up with a message that XXXX (username) does not have sudo access....etc
And lastly, trying to access the virtualmin page over the port 10000 is just returning an "unable to connect" error. [Since I am locked out of using sudo, I am at a loss of how to proceed].
Thank you in advance for your help.
The Apache package we ship is a rebuild of the SRPM from CentOS. The default page is simply an HTML file...it is not "reporting" anything, really, except that you haven't setup any websites yet. On CentOS/RHEL Apache has to be rebuilt in order to support virtual servers in /home when using suexec. So, this is expected behavior and no reason for alarm. We used to ship a custom error page instead (with Virtualmin logo instead of CentOS, but the patch broke a while back and I never got around to fixing it...might go back to that next time we roll an Apache update).
Virtualmin did not touch your sudoers file. That problem is unrelated to the Virtualmin installation. (I wrote the install.sh and the virtualmin-base package; I'm 100% certain your sudoers issue is unrelated to Virtualmin). I don't have any guesses about what went wrong there, or how to fix it if you don't have any way to access the machine as root (rebooting into single user mode would be the right thing if you have hardware access or can get access via a KVM from your hosting provider/colo).
We would need to see the last few dozen lines of the install log to know what went wrong with the Virtualmin installation, and why Webmin failed to start.

Linux XAMPP suddenly requires 32 bit compatibility library

I have been working with linux's version of XAMPP (named LAMPP) for about 3 months now and up until tonight XAMPP has worked fine, but suddenly when I tried to run the command
sudo xampp stop
it gave me this error message:
XAMPP is currently only availably as 32 bit application. Please use a 32 bit compatibility library for your system.
and since then any time I try to run any of the following commands:
sudo xampp start
sudo xampp stop
sudo xampp restart
I get the same message
I want to know why I got this message because xampp has been working flawlessly up until now and in fact, less than 30 minutes ago, I typed sudo xampp start and xampp started up normally and I was able to access localhost/phpmyadmin/
Here is some other info that may be useful:
-My OS is Arch Linux
-I am using the xfce desktop environment
-In the time between starting xampp successfully and trying to stop xampp when I got the error message above, I was trying to get the php mail() function to work by following the steps on this page http://www.absolutelytech.com/2010/07/18/howto-send-emailsusing-mail-function-from-localhost-in-php-through-msmtp-using-gmail-account-on-linux/ and I had just successfully finished step 1 and successfully sent the test email to myself.
-also, when I first got the aforementioned error message, I was still able to access pages via localhost (for instance I had a php file at /opt/lampp/htdocs/Brown/index.php that I could access successfully by typing localhost/Brown/index.php even after I was getting the error message) but then I tried to restart my computer to see if that might fix the issue and now I can't start xampp to begin with.
Please someone help me with this and feel free to ask any follow-up questions if that will help
I figured out my own issue. For anyone who sees this question, I had made a few changes to my php.ini file in attempts to get php's mail() function to work and I wanted to start fresh, so I moved php.ini to php_old.ini and copied a file named php.ini-pre1.7.2 to php.ini thinking that php.ini-pre1.7.2 was a file containing the default configuration of php.ini in case one might want to roll back to the defaults, but instead it is something entirely different. My issue was completely fixed when I moved php_old.ini back to php.ini
2021 and the same happened to me after trying to match php.ini seetings between a Windows environment and a Ubuntu 20.04 one. Everywhere I saw it told me to comment a section in the /opt/lampp/lampp file but it messed up my installation and I lost track of what was wrong. After re-installing LAMPP I matched the settings one by one restarting with sudo opt/lampp/lampp restart at each modification. The culprit was:
browscap="C:\xampp\php\extras\browscap.ini"
This line has to be stay commented (just put a semicolon at the start of the line), if you need it then this workaround may help you. Cheers!

cURL Always Returns 401 With NTLM

I'm working on a library to communicate with Microsoft Exchange using PHP. Everything works fine on my production servers, but I keep getting a 401 Unauthorized on my development machine. I tried using curl from the command line and I get the same results.
Using the following returns "401" on my machine:
curl https://mail.example.com/EWS/Exchange.asmx -w %{http_code} --ntlm -u username:password
The same exact call returns "302" on my production machines, which is what I expect.
My development machine is using curl 7.19.7 and my production machine is using curl 7.18.0.
This is an old question but if it can eventually help anybody, I figured I'd post an answer.
There's a bug with NTLM and curl on certain recent version of Ubuntu (10.04 and up I believe).
Ubuntu: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/675974
CentOS: https://bugzilla.redhat.com/show_bug.cgi?id=799557
If you're using the curl module of PHP on ubuntu and your libcurl version is affected by this bug, this could explain why your authentication requests are failing.
If you add the verbose flag to your command (-v), you should see something like this in the response part:
gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_1000' not found
If you do see this, you're affected by the bug and you'll have to either downgrade your library or find another machine.
I hope this helps :P
For all Centos / RHEL 6.X Users please take a look into:
https://bugzilla.redhat.com/show_bug.cgi?id=953864

Resources