The uWSGI SPDY router setup - uwsgi

Following the instructions from the uWSGI SPDY router docs I didn't have much luck.
I've tried it on a vagrant instance Linux precise64 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Under a virtual environment.
$ python --version
Python 2.7.9
Issuing following command that I derive from the manual does fire up a server:
$ uwsgi --master --https2 addr==0.0.0.0:8443,cert=/home/vagrant/server.crt,key=/home/vagrant/server.key,spdy=asdf --module werkzeug.testapp:test_app --thunder-lock --socket=/tmp/uwsgi.sock --shared-socket :8443 -H /vagrant/venv/
Note that I'm forwarding host 8422 to guest 8443.
The problem is that checking https://spdy.localhost:8442/ doesn't show any Werkzeug variables described in the manual (SPDY, SPDY.version). The UWSGI_ROUTER has value of "http" if that's of any significance.
$ openssl version
OpenSSL 1.0.1 14 Mar 2012
Werkzeug Version 0.10.4
uwsgi.version '2.0.10'
I've made sure tat python doesn't produce insecure platform warning.
The OpenSSL seems to be OK version according to the manual.
There are no warnings or meaningful info messages in the log.
It just doesn't use SPDY routing it seems.
What might be the cause of this?

Related

sstp vpn on Mac OS Big Sur - could not complete write of frame, could not forward packet to pppd

For the past few months I have successfully been using my Mac to connect to a Windows sstp VPN for work using homebrew....until now.
I followed the instructions here:
Windows SSTP VPN - connect from Mac
and use this command:
sudo /usr/local/sbin/sstpc --log-stderr --cert-warn --user <user> --password <password> <server> usepeerdns require-mschap-v2 noauth noipdefault defaultroute refuse-eap noccp
Now, out of nowhere, I get an error:
Mar 24 12:20:50 sstpc[5481]: Could not complete write of frame
Mar 24 12:20:50 sstpc[5481]: Could not forward packet to pppd
Mar 24 12:20:50 sstpc[5481]: Could not complete write of frame
Mar 24 12:20:50 sstpc[5481]: Could not forward packet to pppd
Mar 24 12:20:51 sstpc[5481]: Connection was aborted, Reason was not known
**Error: Connection was aborted, Reason was not known, (-1)
The numbers in the brackets sstpc[nnnn] vary, they're not always what is above.
I tried updating homebrew, reinstalling the sstp-client from homebrew, restarting my computer.
What else can I try?
There is a serious bug in sstp-client 1.0.14 which causes this [1], you likely need to downgrade to 1.0.13.
Unfortunately homebrew does not have tagged versions for sstp-client, so it is a little more involved - you will need to create a local tap so you can pin the version:
$ brew uninstall sstp-client
$ brew tap-new mymac/local
$ brew extract --version 1.0.13 sstp-client mymac/local
$ brew install mymac/local/sstp-client#1.0.13
Now it should work as before.
[1] https://sourceforge.net/p/sstp-client/discussion/1499218/thread/d485651bda/?limit=25#268f/038f/4b89/f7be/ffd5

Loop crashes with Falco

I'm currently experimenting with Falco (a runtime monitoring solution for container).
I'm working locally on a Mac (Catalina v10.15.3), have Helm (v3.1.2) installed, Docker (version 2.2.0.5 (43884)) and K8s running (v1.15.5).
I try deploying Falco using helm as suggest in their installation page and I end up in a loop of crash for the pod.
Here are the logs that I get :
$ kubectl logs falco-xxxxx
* Setting up /usr/src links from host
ln: failed to create symbolic link '/usr/src//host/usr/src/*': No such file or directory
* Unloading falco-probe, if present
* Running dkms install for falco
Error! echo
Your kernel headers for kernel 4.19.76-linuxkit cannot be found at
/lib/modules/4.19.76-linuxkit/build or /lib/modules/4.19.76-linuxkit/source.
* Running dkms build failed, couldn't find /var/lib/dkms/falco/0.20.0+d77080a/build/make.log
* Trying to load a system falco-probe, if present
* Trying to find precompiled falco-probe for 4.19.76-linuxkit
Found kernel config at /proc/config.gz
* Trying to download precompiled module from https://s3.amazonaws.com/download.draios.com/stable/sysdig-probe-binaries/falco-probe-0.20.0%2Bd77080a-x86_64-4.19.76-linuxkit-f9de4c19ddd4080798f0e14972190e35.ko
curl: (22) The requested URL returned error: 404 Not Found
Download failed, consider compiling your own falco-probe and loading it or getting in touch with the Falco community
Thu Apr 2 15:39:47 2020: Falco initialized with configuration file /etc/falco/falco.yaml
Thu Apr 2 15:39:47 2020: Loading rules from file /etc/falco/falco_rules.yaml:
Thu Apr 2 15:39:48 2020: Loading rules from file /etc/falco/falco_rules.local.yaml:
Thu Apr 2 15:39:49 2020: Unable to load the driver. Exiting.
Thu Apr 2 15:39:49 2020: Runtime error: error opening device /dev/falco0. Make sure you have root credentials and that the falco-probe module is loaded.. Exiting.
I looked around a bit and didn't find a clue so I took the liberty to ask directly here before trying to compile the probe myself.
Do you have any idea how to fix this issue ?

TinyTds fails to connect to azure on Debian

I'm trying to connect to a Azure SQL database using tiny-tds gem on ruby 2.2.3. I installed freetds-dev and freetds-bin and everything seems to work just fine there.
tsql -C
Compile-time settings (established with the "configure" script)
Version: freetds v0.91
freetds.conf directory: /etc/freetds
MS db-lib source compatibility: no
Sybase binary compatibility: yes
Thread safety: yes
iconv library: yes
TDS version: 4.2
iODBC: no
unixodbc: yes
SSPI "trusted" logins: no
Kerberos: yes
and doing
TDSVER=7.1 tsql -U xxxxx -P xxxxx -H mydatabase.database.windows.net -p 1433
connects just fine (I get a prompt).
I installed tiny_tds gem:
/home/avril14th/.rvm/gems/ruby-2.2.3/gems/tiny_tds-0.7.0
and tried to connect
avril14th#avril14th:~/src/white2$ pry
[1] pry(main)> require 'tiny_tds'
=> true
[2] pry(main)> client = TinyTds::Client.new username: 'xxxx', password: 'xxxxx', host: 'xxxxx.database.windows.net', :azure => true
TinyTds::Error: Adaptive Server connection failed
I've tried a lot of other combinations of parameters, as described at tiny_tds github page and none worked.
Any help is appreciated. I've been trying at this for over 5 hours now...What puzzles me is that it always fails instantly so it's not a question of timeout.
This has nothing to do with the version of TinyTDS, it has supported Azure for some time. The issue is how FreeTDS is compiled. It is lacking being compiled with OpenSSL support which is required by Azure. When done, you will see OpenSSL: yes in your output from tsql -C above.
We talk about this in our Using TinyTDS with Azure section of the readme.
ADDED: The reason TinyTDS 1.0 in master branch can connect is due to that version compiling OpenSSL and FreeTDS locally. That is a new feature that is not yet ready for public consumption yet. Depending on your needs and usage of system level FreeTDS, use either or... but the answer is still correct, the reason you could not use v0.7 for Azure is due to your system FreeTDS not having OpenSSL linked.

How to restart FastCGI process from source?

I have Plesk 12, and I installed another version of PHP using this guide. I switched a specific domain to use this version. So in the hosting settings, it says
PHP support (Run PHP as [FastCGI application], PHP version 5.3.1
Now, I needed to edit the php.ini file to turn on short tags (eww gross I know), but I can't turn them on. When I run service apache2 restart it doesn't restart FastCGI. It is installed at /usr/local/php531-cgi
ls -l
-rw-r--r-- 1 root root 1204 Mar 18 22:47 pear.conf
-rw-r--r-- 1 root root 69623 Mar 18 23:36 php.ini
I tried restarting the entire server, setting ini_set('short_open_tag',true);, and the commands service php5-fpm restart / service php-fpm restart
But the results are the same, short_open_tag Off
I followed #mario's advice, and checked phpinfo(). I was using the wrong php.ini file. I was using /usr/local/php531-cgi/etc/php.ini. The one I needed to use was in /var/www/vhosts/system/[domainname.com]/php.ini
I didnt even need to restart anything. Thanks Mario!
a quick command to see which php.ini file you're using
php -i | grep /php.ini

SSL certificate for curl disappears after Mountain Lion upgrade

I recently upgraded to OS X Mountain Lion, and when I run curl-config --ca I get an empty line. Details about curl:
curl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
The issue is that I can't run brew update unless I update the certificate because I get the following error:
Initialized empty Git repository in /usr/local/.git/
error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://github.com/mxcl/homebrew.git/info/refs
fatal: HTTP request failed
Error: Failure while executing: git fetch origin
The homebrew help forums say I need to update the certificate. However, unless I can find where curl is storing the certificate, I can't update it.
EDIT: The solution presented by HeatfanJohn below:
I just noticed that there is a Macport for curl-ca-bundle. Sorry for the possibly simple question, but did you install curl or did it come preinstalled? You might want to consider installing MacPorts and then installing curl-ca-bundle using MacPorts, although looking quickly at the Portfile this MacPort appears to just put the bundle into /usr/share which you can also do manually.
The command to install from MacPorts is port install curl. Installing from MacPorts resolves the issue.
I mostly run curl on Winodws, but from the curl documentation the following should work:
If you're using the curl command line tool, you can specify your own
CA cert path by setting the environment variable CURL_CA_BUNDLE to the
path of your choice.
Then download the lastest .pem file from http://curl.haxx.se/ca/cacert.pem placing the .pem in the directory path that you specify in the CURL_CA_BUNDLE environment variable. The documentation is a little vague as to whether the environment variable points to the file or directory. I would try pointing it to the file.
On Windows, curl looks for the .pem file as file curl-ca-bundle.crt in the same directory where the curl executable lives. That may also work. I have an old MAC at home. I will test this later tonight.
curl-config --ca returns /usr/share/curl/curl-ca-bundle.crt for me.
I just noticed that there is a Macport for curl-ca-bundle. Sorry for the possibly simple question, but did you install curl or did it come preinstalled? You might want to consider installing MacPorts and then installing curl-ca-bundle using MacPorts, although looking quickly at the Portfile this MacPort appears to just put the bundle into /usr/share which you can also do manually.
I installed curl from Macports and now I have version 7.27.0 installed and it is configured to use the latest curl-ca-bundle.crt file. See below:
sams-mac:~ sam$ curl --version
curl 7.27.0 (powerpc-apple-darwin8.11.0) libcurl/7.27.0 OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
sams-mac:~ sam$ curl-config --ca
/opt/local/share/curl/curl-ca-bundle.crt
sams-mac:~ sam$ ls -l /opt/local/bin/curl*
-rwxr-xr-x 1 root admin 147012 Aug 3 11:00 /opt/local/bin/curl
-rwxr-xr-x 1 root admin 4988 Aug 3 11:00 /opt/local/bin/curl-config
sams-mac:~ sam$

Resources