Kind of a noob question. I'm uploading to a remote server. I've been advised to debug locally (versus remotely). How am I to pull up my files in a browser, then use the debugging tools in PhpStorm? As it stands, my remote host (in PhpStorm) is configured. I've done my own research but can't seem to find a clear answer. Thanks!
There is a "zero-configuration" debugging as described in docs. Also if in trouble try this xdebug settings:
; path to your php_xdebug extension file
; download from https://xdebug.org/wizard.php
zend_extension="c:\xampp-php7\php\ext\php_xdebug-2.4.0-7.0-vc14.dll"
; disables profiler globally
xdebug.profiler_enable = 0
; allows enabling it selectively with request parameter "XDEBUG_PROFILE"
xdebug.profiler_enable_trigger = 1
; directory to output profiler files to
xdebug.profiler_output_dir = "C:\xampp-php7\tmp"
; profiler file name (with request uri and timestamp)
xdebug.profiler_output_name = "%R-%t.cgout"
; enables debugger
xdebug.remote_enable = 1
; selects the dbgp protocol
xdebug.remote_handler = "dbgp"
; host where debug client is running
xdebug.remote_host = "localhost"
; debugger port
xdebug.remote_port = 9000
; disables xdebug traces in error messages - use https://tracy.nette.org/ instead
xdebug.default_enable = "Off"
; makes sure that the process does not freeze when there is no debug client
xdebug.remote_autostart = 0
I created a gist for easier sharing
Related
I have a practically vanilla install of PgBouncer on Windows Server 2019 Datacenter, downloaded using "Application Stack Builder". I'm trying to connect to a Postgres 11 database, local to the server.
The only config change I've done is to specify the database and the location of the log and PID files. Here's my config, taken from the Github pgbouncer-minimal.ini:
;;; This is an almost minimal starter configuration file that only
;;; contains the settings that are either mandatory or almost always
;;; useful. All settings show their default value.
[databases]
;; add yours here
postgres = host=localhost port=7450 user=postgres password=postgres
;; fallback
;* =
[pgbouncer]
;; required in daemon mode unless syslog is used
logfile = log/pgbouncer.log
;; required in daemon mode
pidfile = log/pgbouncer.pidfile
syslog = 0
;; set to enable TCP/IP connections
;listen_addr =
;; PgBouncer port
;listen_port = 6432
;; some systems prefer /var/run/postgresql
;unix_socket_dir = /tmp
;; change to taste
auth_type = trust
;; probably need this
auth_file = etc/userlist.txt
;; pool settings are perhaps best done per pool
;pool_mode = session
;default_pool_size = 20
;; should probably be raised for production
;max_client_conn = 100
Why do I keep getting the following error in the logs and how can I fix this?
2022-07-01 12:27:11.711 Coordinated Universal Time [8724] FATAL could not open /dev/null: The system cannot find the file specified.
I have installed maradns in windows 7 machine, I have configured it, It can able to handle internal requests, But not external ones
marac file
ipv4_bind_addresses = "127.0.0.1"
timestamp_type = 2
random_seed_file = "secret.txt"
csv2 = {}
csv2["myapp.com."] = "db.lan.txt"
upstream_servers = {} # Initialize dictionary variable
upstream_servers["."] = "8.8.8.8, 8.8.4.4"
db.lan.txt
private.% 192.168.1.21 ~
blog.% 192.168.1.16 ~
For external requests, its giving me the below error
C:\Program Files\maradns-2-0-06-win32>askmara.exe Agoogle.com.
# Querying the server with the IP 127.0.0.1
# Remote server said: REFUSED
# NS replies:
# AR replies:
For internal requests, Its working fine as below
C:\Program Files\maradns-2-0-06-win32>askmara.exe Aprivate.myapp.com.
# Querying the server with the IP 127.0.0.1
# Question: Aprivate.myapp.com.
private.myapp.com. +86400 a 192.168.1.21
# NS replies:
#myapp.com. +86400 ns synth-ip-7f000001.myapp.com.
# AR replies:
#synth-ip-7f000001.myapp.com. +86400 a 127.0.0.1
And when i start the server, I am getting a prompt with a warning as well
How to resolve this issue.
i had the same problem.. fixed it by replacing the latest version with the version 1.4..
after that the only i did was run the mkSecretTxt.exe to create the secret.txt file and configured the mararc file like this:
this is my current mararc file:
# Win32-specific MaraRC file; this makes a basic recursive DNS
# server.
hide_disclaimer = "YES"
ipv4_bind_addresses = "127.0.0.1"
recursive_acl = "127.0.0.1/8"
timestamp_type = 2
csv2 = {}
csv2["local.com."] = "db.lan.txt"
# This is insecure until the secret.txt file is edited
random_seed_file = "secret.txt"
upstream_servers = {}
upstream_servers["."] = "208.67.222.222,208.67.220.220"
db.lan.txt
% 192.168.1.33 ~
As you can see i've used the openDNS servers, if your still get the error try them as well.
http://www.opendns.com/support/article/105
cheers
For anyone following along with this, it seems the current solution as of MaraDNS > 2.0 is to use MaraDNS in conjunction with the included Deadwood recursive server to be able to handle both local and external resolution. I was able to get this working on my Windows 10 machine with the following configs...
Assume that the Windows machine's IP address is 192.168.1.2
In the MaraDNS mararc file:
ipv4_bind_addresses = "127.0.0.1"
timestamp_type = 2
random_seed_file = "secret.txt"
csv2 = {}
csv2["mylocalnet.com."] = "db.lan.txt"
In the db.lan.txt file:
% 192.168.1.XXX ~
And in the Deadwood dwood3rc.txt config file:
upstream_servers = {}
upstream_servers["."]="8.8.8.8, 8.8.4.4"
upstream_servers["mylocalnet.com."]="127.0.0.1"
bind_address="192.168.1.2"
recursive_acl = "127.0.0.1/16, 192.168.1.1/24"
# By default, for security reasons, Deadwood does not allow IPs in the
# 192.168.x.x, 172.[16-31].x.x, 10.x.x.x, 127.x.x.x, 169.254.x.x,
# 224.x.x.x, or 0.0.x.x range. If using Deadwood to resolve names
# on an internal network, uncomment the following line:
filter_rfc1918 = 0
You could potentially set up multiple machines to act as independent servers, but my config above was particular in that in enabled me to run both servers on the same machine. You can see that in the Deadwood config, I'm using Google's DNS servers to handle all upstream requests with the exception of mylocalnet.com. which gets forwarded to localhost and handled by MaraDNS.
From here, you just need to launch both programs and point DNS to 192.168.1.2. Should be good to go!
I've developed an application that connects to the PayPal API with libcurl, which I use through the OCurl bindings for OCaml from a process running on a Debian server. The code always works when inside the Paypal sandbox (endpoint https://api-3t.sandbox.paypal.com/nvp) but never works when connecting to the actual Paypal servers (endpoint https://api-3t.paypal.com/nvp).
Libcurl always returns CURLE_RECV_ERROR. The general consensus is that this error happens when there is a network problem, so I have investigated that.
I ran the exact same request with the command-line curl tool from the exact same server, using the exact same process uid/gid, and it consistently works. Tracking the transfers with tcpdump does not reveal any significant difference in the structure of transactions made by the working command-line curl and the non-working application, so it all appears as if the HTTP request is successfully performed in both cases. Then again, it's HTTPS, so I cannot be certain.
Here is the OCaml code that performs the request:
let c = new Curl.handle in
let buffer = Buffer.create 1763 in
c # set_url "https://api-3t.paypal.com/nvp" ;
c # set_post true ;
c # set_postfields "SOMEDATA" ;
c # set_postfieldsize (String.length "SOMEDATA") ;
c # set_writefunction (fun x -> Buffer.add_string buffer x ; String.length x) ;
c # perform ;
c # cleanup ;
Buffer.contents buffer
Here is the equivalent curl command line:
curl -X POST https://api-3t.paypal.com/nvp -d SOMEDATA
EDIT: By increasing the libcurl verbosity, I determined that the underlying error is this:
GnuTLS recv error (-9): A TLS packet with unexpected length was received.
What could be the cause of this error? How can I investigate to find out?
EDIT 2: It appears that the difference between command-line and library use is that the command-line version is linked to OpenSSL and the library is linked to GnuTLS.
How do I link both to OpenSSL?
First, the key to further debugging those issues is to use curl's debugging facilities, namely the VERBOSE setting (and also, possibly, the DEBUGFUNCTION setting for printing the data your way).
c # set_verbose true ;
This identified the error as being a problem with GnuTLS that is also discussed here, and which is solved by setting SSLVERSION to 3 to force the use of SSLv3.
c # set_sslversion 3 ;
I always call curl#set_postfieldsize to the length of the data passed to curl#set_postfields. My code would be, then:
let make_get url =
let curl = new Curl.handle in
curl#set_writefunction String.length; (* ignore result *)
curl#set_tcpnodelay true;
curl#set_verbose false;
curl#set_post false;
curl#set_url url;
curl
let make_post url =
let curl = make_get url in
curl#set_post true;
curl#set_httpheader [
"Content-Type: text/xml; charset=\"UTF-8\"";
"SOAPAction: \"\"";
];
curl#set_postfields xml;
curl#set_postfieldsize (String.length xml);
curl
I hope this helps.
I am trying to send an email from R, using the sendmailR package. The code below works fine when I run it on my PC, and I recieve the email. However, when I run it with my macbook pro, it fails with the following error:
library(sendmailR)
from <- sprintf("<sendmailR#%s>", Sys.info()[4])
to <- "<myemail#gmail.com>"
subject <- "TEST"
sendmail(from, to, subject, body,
control=list(smtpServer="ASPMX.L.GOOGLE.COM"))
Error in socketConnection(host = server, port = port, blocking = TRUE) :
cannot open the connection
In addition: Warning message:
In socketConnection(host = server, port = port, blocking = TRUE) :
ASPMX.L.GOOGLE.COM:25 cannot be opened
Any ideas as to why this would work on a PC, but not a mac? I turned the firewall off on both machines.
Are you able to send email via the command-line?
So, first of all, fire up a Terminal and then
$ echo “Test 123” | mail -s “Test” user#domain.com
Look into /var/log/mail.log, or better use
$ tail -f /var/log/mail.log
in a different window while you send your email. If you see something like
... setting up TLS connection to smtp.gmail.com[xxx.xx.xxx.xxx]:587
... Trusted TLS connection established to smtp.gmail.com[xxx.xx.xxx.xxx]:587:\
TLSv1 with cipher RC4-MD5 (128/128 bits)
then you succeeded. Otherwise, it means you have to configure you mailing system. I use postfix with Gmail for two years now, and I never had have problem with it. Basically, you need to grab the Equifax certificates, Equifax_Secure_CA.pem from here: http://www.geotrust.com/resources/root-certificates/. (They were using Thawtee certificates before but they changed last year.) Then, assuming you used Gmail,
Create relay_password in /etc/postfix and put a single line like this (with your correct login and password):
smtp.gmail.com login#gmail.com:password
then in a Terminal,
$ sudo postmap /etc/postfix/relay_password
to update Postfix lookup table.
Add the certificates in /etc/postfix/certs, or any folder you like, then
$ sudo c_rehash /etc/postfix/certs/
(i.e., rehash the certificates with Openssl).
Edit /etc/postfix/main.cf so that it includes the following lines (adjust the paths if needed):
relayhost = smtp.gmail.com:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_password
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
smtp_tls_CApath = /etc/postfix/certs
smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_loglevel = 1
tls_random_source = dev:/dev/urandom
Finally, just reload the Postfix process, with e.g.
$ sudo postfix reload
(a combination of start/stop works too).
You can choose a different port for the SMTP, e.g. 465.
It’s still possible to use SASL without TLS (the above steps are basically the same), but in both case the main problem is that your login informations are available in a plan text file... Also, should you want to use your MobileMe account, just replace the Gmail SMTP server with smtp.me.com.
I've had success with LuaSocket's TCP facility, but I'm having trouble with its FTP module. I always get a timeout when trying to retrieve a (small) file. I can download the file just fine using Firefox or ftp in passive mode (on Ubuntu Dapper Linux).
I thought it might be that I need LuaSocket to use passive FTP, but then I found that it seems to do that by default. The file I'm trying to retrieve via FTP can be accessed with passive FTP via other programs on my machine, but not via active mode. I found some talk about "hacking" passive mode support into LuaSocket, and that discussion implies that later versions stopped using passive mode, but my version seems to use passive anyway (I'm using 2.0.1; newest is 2.0.2 and does not appear to have any changes relevant to my use case). I'm a little confused about how that post may relate to my situation, partly because it's very old and LuaSocket's source now bears little resemblance to the code in that discussion).
I've boiled my code down to this:
local ftp = require "socket.ftp"
ftp.TIMEOUT = 10
print(ftp.get("ftp://ftp.us.dell.com/app/dpart.txt"))
This gives me a timeout. I ran it under strace on Linux (same as ptrace on Solaris). Here's an abridged transcript:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
recv(3, "230-Welcome to the Dell FTP site."..., 8192, 0) = 971
send(3, "pasv\r\n", 6, 0) = 6
recv(3, 0x8089a58, 8192, 0) = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], NULL, NULL, {9, 999934}) = 0 (Timeout)
There's another site I tried connecting to, but it has a password which I can't post here, but in that case the results were slightly different...I got trace like the above but with select() succeeding at the end, then this:
recv(3, "227 Entering Passive Mode (123,456,789,0,12,34)\r\n", 8192, 0) = 49
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(12345), sin_addr=inet_addr("123.456.789.0")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(5, [4], [4], NULL, {9, 999694}) = 0 (Timeout)
Compare this to the trace of my "ftp" program in passive mode (which works fine, though note that it does not set the sockets to nonblocking like LuaSocket does):
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
write(5, "PASV\r\n", 6) = 6
read(3, "227 Entering Passive Mode (123,456,789,0,12,34)\r\n", 1024) = 51
connect(6, {sa_family=AF_INET, sin_port=htons(12345), sin_addr=inet_addr("123.456.789.0")}, 16) = 0
So I've tried LuaSocket against these two different FTP sites with different but similar failures. I also tried it from another machine where active FTP works, and it didn't have any better luck there (presumably because LuaSocket is always using passive mode, from what I can tell by reading the source in socket/ftp.lua).
So can anyone here make the LuaSocket two-liner at the top work? Note that on my machine, active FTP to Dell's site doesn't work (I can connect but as soon as I do ls it disconnects), so if you get LuaSocket to work please also note whether active FTP to Dell's site from another program works on your machine.
Hm. It looks like the problem is that LuaSocket uses "pasv" in lower case. I'm going try to figure out a work-around.
Hm. Nope, it looks quite elegantly welded shut. The easiest thing to do is probably to copy that particular file to its equivalent place in a hierarchy in an earlier path in LUA_PATH. That is, (usually) make a local copy of the file, e.g. path/to/your/project/socket/ftp.lua.
Then edit the local file:
- self.try(self.tp:command("user", user or USER))
+ self.try(self.tp:command("USER", user or USER))
- self.try(self.tp:command("pass", password or PASSWORD))
+ self.try(self.tp:command("PASS", password or PASSWORD))
- self.try(self.tp:command("pasv"))
+ self.try(self.tp:command("PASV"))
- self.try(self.tp:command("port", arg))
+ self.try(self.tp:command("PORT", arg))
- local command = sendt.command or "stor"
+ local command = sendt.command or "STOR"
- self.try(self.tp:command("cwd", dir))
+ self.try(self.tp:command("CWD", dir))
- self.try(self.tp:command("type", type))
+ self.try(self.tp:command("TYPE", type))
- self.try(self.tp:command("quit"))
+ self.try(self.tp:command("QUIT"))
Perversely, a navelnaut expedition using getfenv, getmetatable, etc didn't seem to be worth it. I consider it a serious problem with the design. (of LuaSocket)
It's worth noting that RFC0959 uses all-caps commands. (Probably because it's from the 7-bit ASCII era.)
Note that the server is failing to follow the FTP specification, which states commands are case-insensitive. See RFC959, section 5.3 "The command codes are four or fewer alphabetic characters.
Upper and lower case alphabetic characters are to be treated
identically. Thus, any of the following may represent the
retrieve command:
RETR Retr retr ReTr rETr"
This problem is now fixed, with the question and first answer a great help.
Luasocket is correct to RFC 959 (first comment here is not right about upper case, see RFC959 section 5.2)
At least Microsoft FTP server is not compliant. There might be others.
The solution is change pasv to PASV and is a workaround for a command case sensitive server. Details are on the Lua email list, where the archive will be web accessible in a few days.
(edit line 59 of ftp.lua)