os: windows 7
web server: xampp 1.8.2 (php version: 5.4.27)
phpstorm: 6.0.3
in php.ini:
[XDebug]
zend_extension = "D:\xampp\php\ext\php_xdebug-2.2.4-5.4-vc9.dll"
;xdebug.default_enable=1
;xdebug.auto_trace=1
;xdebug.show_exception_trace = 1
;xdebug.collect_vars = 1
;xdebug.collect_params=1
;xdebug.collect_return=1
;xdebug.profiler_append = 1
;xdebug.profiler_enable = 1
;xdebug.profiler_enable_trigger = 1
xdebug.profiler_output_dir = "D:\xampp\tmp"
xdebug.profiler_output_name = "cachegrind.out.%t-%s"
xdebug.remote_enable = 0
;xdebug.remote_autostart = off
xdebug.remote_handler = "dbgp"
xdebug.remote_host = "localhost"
xdebug.trace_output_dir = "D:\xampp\tmp"
xdebug.remote_mode = "req"
xdebug.remote_port = 9001
xdebug.idekey="PHPSTORM"
when I debug web application in phpstorm. xdebug is working but as same as running.
I have set some breakpoints, but it does not stop there.
You have debugger disabled because of xdebug.remote_enable = 0 config line.
It has to be 1 (on/true).
http://confluence.jetbrains.com/display/PhpStorm/Xdebug+Installation+Guide
Related
I have an InfluxDB Version 1.8.9, but I can't start it.
In this example I'm logged in as a root.
netstat -lptn
gives me a range of services, none of them seem to listen to 8086. (there are other services running like grafana or MySQL, which seem to work fine)
To further confirm nothing is on 8086,I listened to that related Issue run: open server: open service: listen tcp :8086: bind: address already in use on starting influxdb
and run
netstat -a | grep 8086
which results in no results.
My config file on /etc/influxdb/influxdb.conf looks like this:
reporting-disabled = false
bind-address = "127.0.0.1:8086"
[meta]
#dir = "/root/.influxdb/meta"
dir = "/var/lib/influxdb/meta"
retention-autocreate = true
logging-enabled = true
[data]
dir = "/var/lib/influxdb/data"
index-version = "inmem"
wal-dir = "/var/lib/influxdb/wal"
wal-fsync-delay = "0s"
validate-keys = false
strict-error-handling = false
query-log-enabled = true
cache-max-memory-size = 1073741824
cache-snapshot-memory-size = 26214400
cache-snapshot-write-cold-duration = "10m0s"
compact-full-write-cold-duration = "4h0m0s"
compact-throughput = 50331648
compact-throughput-burst = 50331648
max-series-per-database = 1000000
max-values-per-tag = 100000
max-concurrent-compactions = 0
max-index-log-file-size = 1048576
series-id-set-cache-size = 100
series-file-max-concurrent-snapshot-compactions = 0
trace-logging-enabled = false
tsm-use-madv-willneed = false
...
[http]
enabled = true
bind-address = ":8086"
auth-enabled = false
log-enabled = true
suppress-write-log = false
write-tracing = false
flux-enabled = false
flux-log-enabled = false
pprof-enabled = true
pprof-auth-enabled = false
debug-pprof-enabled = false
ping-auth-enabled = false
prom-read-auth-enabled = false
https-enabled = false
https-certificate = "/etc/ssl/influxdb.pem"
https-private-key = ""
max-row-limit = 0
max-connection-limit = 0
shared-secret = ""
realm = "InfluxDB"
unix-socket-enabled = false
unix-socket-permissions = "0777"
bind-socket = "/var/run/influxdb.sock"
max-body-size = 25000000
access-log-path = ""
max-concurrent-write-limit = 0
max-enqueued-write-limit = 0
enqueued-write-timeout = 30000000000
...
So i tried to start my database:
service influxdb start
Which gives me
ob for influxdb.service failed because a timeout was exceeded. See
"systemctl status influxdb.service" and "journalctl -xe" for details.
result of systemctl status influxdb.service
● influxdb.service - InfluxDB is an open-source, distributed, time series database
Loaded: loaded (/lib/systemd/system/influxdb.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2021-09-21 18:37:12 CEST; 1min 7s ago
Docs: https://docs.influxdata.com/influxdb/
Main PID: 32016 (code=exited, status=1/FAILURE); Control PID: 5874 (influxd-systemd)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/influxdb.service
├─5874 /bin/bash -e /usr/lib/influxdb/scripts/influxd-systemd-start.sh
└─5965 sleep 10
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.515897Z lvl=info msg="Registered diagnostics client" log_id=0WjJLI7l000 service=monitor name=runtime
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.515907Z lvl=info msg="Registered diagnostics client" log_id=0WjJLI7l000 service=monitor name=network
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.515923Z lvl=info msg="Registered diagnostics client" log_id=0WjJLI7l000 service=monitor name=system
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.515977Z lvl=info msg="Starting precreation service" log_id=0WjJLI7l000 service=shard-precreation check_interval=10m advanc
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.515995Z lvl=info msg="Starting snapshot service" log_id=0WjJLI7l000 service=snapshot
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.516015Z lvl=info msg="Starting continuous query service" log_id=0WjJLI7l000 service=continuous_querier
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.516011Z lvl=info msg="Storing statistics" log_id=0WjJLI7l000 service=monitor db_instance=_internal db_rp=monitor interval=
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.516037Z lvl=info msg="Starting HTTP service" log_id=0WjJLI7l000 service=httpd authentication=false
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: ts=2021-09-21T16:37:23.516052Z lvl=info msg="opened HTTP access log" log_id=0WjJLI7l000 service=httpd path=stderr
Sep 21 18:37:23 s22227708 influxd-systemd-start.sh[5874]: run: open server: open service: listen tcp :8086: bind: address already in use
I can't really understand where I did something wrong, since I configured :8086 in the config file. Can you help me?
It appears to be a typo in the configuration file.
As stated in the documentation, the configuration file should hold http-bind-address instead of bind-address. As well as a locked port by the first configuration.
The first few lines of the file /etc/influxdb/influxdb.conf should look like so:
reporting-disabled = false
http-bind-address = "127.0.0.1:8086"
A suggested approach would be to:
bind-address to http-bind-address
Changing the port from default 8086 to a known free port
(Optional) Back to the default port.
From your config:
reporting-disabled = false
bind-address = "127.0.0.1:8086"
...
[http]
enabled = true
bind-address = ":8086"
Both your 'native' service and the 'http' service are configured to use the same port 8086. This cannot work and you probably want to change the 'native' port back to its default of 8088.
I met a really weird issue: I'm able to connect to my SQL Server with tsql but I'm not able to do the same with pymssql. Let me give you more details.
With this kind of tsql command everything seems to be ok:
$ tsql -H '10.10.10.2' -U 'DOMAIN\myuser' -p 63849
Password:
locale is "fr_FR.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
1>
But with the following basic python script I got an issue:
$ cat test_mssql.py
# -*- coding: utf8 -*-
import pymssql
import pandas as pd
conn = pymssql.connect(server=r'10.10.10.2', user=r'DOMAIN\myuser', password='mypassword', port='63849')
$ python test_mssql.py
Traceback (most recent call last):
File "api-vinci-rh/current/test_mssql.py", line 60, in <module>
conn = pymssql.connect(server=r'10.10.10.2', user=r'DOMAIN\myuser', password='mypassword', port='63849')
File "pymssql.pyx", line 641, in pymssql.connect (pymssql.c:10788)
pymssql.OperationalError: (20002, 'DB-Lib error message 20002, severity 9:\nAdaptive Server connection failed\n')
By activating TDSDUMPCONFIG env variable, I can see a difference between the tls command and my python script:
TDSDUMPCONFIG tls trace
config.c:224:Final connection parameters:
config.c:225: server_name = 10.10.10.2
config.c:226: server_host_name = 10.10.10.2
config.c:227: ip_addr = 10.10.10.2
config.c:228: instance_name =
config.c:229: port = 63849
config.c:230: major_version = 7
config.c:231: minor_version = 1
config.c:232: block_size = 0
config.c:233: language = us_english
config.c:234: server_charset =
config.c:235: connect_timeout = 0
config.c:236: client_host_name = myhost
config.c:237: client_charset = UTF-8
config.c:238: app_name = TSQL
config.c:239: user_name = DOMAIN\myuser
config.c:242: library = TDS-Library
config.c:243: bulk_copy = 0
config.c:244: suppress_language = 0
config.c:245: encrypt level = 0
config.c:246: query_timeout = 0
config.c:249: database =
config.c:250: dump_file = /tmp/freetds.log
config.c:251: debug_flags = 0
TDSDUMPCONFIG pymssql trace
config.c:224:Final connection parameters:
config.c:225: server_name = 10.10.10.2:63849
config.c:226: server_host_name = 10.10.10.2
config.c:227: ip_addr = 10.10.10.2
config.c:228: instance_name =
config.c:229: port = 63849
config.c:230: major_version = 7
config.c:231: minor_version = 1
config.c:232: block_size = 0
config.c:233: language = us_english
config.c:234: server_charset =
config.c:235: connect_timeout = 0
config.c:236: client_host_name = myhost
config.c:237: client_charset = UTF-8
config.c:238: app_name = pymssql=2.1.2
config.c:239: user_name =
config.c:242: library = DB-Library
config.c:243: bulk_copy = 0
config.c:244: suppress_language = 0
config.c:245: encrypt level = 0
config.c:246: query_timeout = 0
config.c:249: database =
config.c:250: dump_file = /tmp/freetds.log
config.c:251: debug_flags = 0
config.c:252: text_size = 64512
config.c:253: broken_dates = 0
config.c:254: emul_little_endian = 0
config.c:255: server_realm_name =
I think the 2 main differences is about the user_name which is empty with the python script and the library which is DB-Library instead of TDS-Library.
I currently find no way to force these parameters in the python script and I find no clue about my issue (the error message is a generic one).
I'm using python 2.7.9 and pymssql==2.1.2
More info about my env:
$ 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
$ grep -v '^#' /etc/freetds/freetds.conf
[global]
tds version = 7.1
dump file = /tmp/freetds.log
text size = 64512
enable gssapi delegation = off
If you have any clue to help let me know.
Edit: I have another SQL Server instance for my test and my python script works... the username in the TDSDUMPCONFIG is set. So Iguess there is something strange on my env but don't know what
I find a clue and I'm quite surprised byt it... If I use a username with less than 32 characters, I have no more issue with pymssql ! I didn't find anything about this weird bug (?) but I promess it fixes my issue.
I need to see the code of pymssql and see if I find any lenght restriction or issue about the lenght of the username
I seem to be having an issue with the pro bono tac_plus configuration.
my switch is giving me the following log message
May 4 20:58:52 sv5-c1-r104-ae02 Aaa: %AAA-4-EXEC_AUTHZ_FAILED: User jdambly failed authorization to start a shell
if I look at the tac_plus logs it looks like my group mapping is not configured correctly, here is the log
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: Start authorization request
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: cfg_get: checking user/group jdambly, tag (NULL)
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: cfg_get: checking user/group jdambly, tag (NULL)
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: user 'jdambly' found
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: cfg_get: checking user/group jdambly, tag (NULL)
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: jdambly#192.168.0.19: not found: svcname=shell#world protocol=
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: jdambly#192.168.0.19: not found: svcname=shell protocol=
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: jdambly#192.168.0.19: svcname=shell protocol= not found, default is <unknown>
May 4 14:04:22 neteng tac_plus[14476]: 1/9a920270: Writing AUTHOR/FAIL size=18
here is my config
id = tac_plus {
debug = PACKET AUTHEN AUTHOR MAVIS
access log = /var/log/tac_plus/access.log
accounting log = /var/log/tac_plus/acct.log
authorization log = /var/log/tac_plus/auth.log
mavis module = external {
setenv LDAP_SERVER_TYPE = "microsoft"
#setenv LDAP_HOSTS = "ldaps://xxxxxx:3268"
setenv LDAP_HOSTS = "xxxxxx:3268"
setenv LDAP_SCOPE = sub
setenv LDAP_BASE = "dc=nskope,dc=net"
setenv LDAP_FILTER = "(&(objectclass=user)(sAMAccountName=%s))"
setenv LDAP_USER = "xxxx#nskope.net"
setenv LDAP_PASSWD = "xxxxxxxx"
#setenv AD_GROUP_PREFIX = devops
# setenv REQUIRE_AD_GROUP_PREFIX = 1
# setenv USE_TLS = 0
exec = /usr/local/lib/mavis/mavis_tacplus_ldap.pl
}
user backend = mavis
login backend = mavis
pap backend = mavis
skip missing groups = yes
host = world {
address = 0.0.0/0
prompt = "Welcome\n"
key = cisco
}
group = devops {
default service = permit
service = shell {
default command = permit
default attribute = permit
set priv-lvl = 15
}
}
}
I'm trying to map the ad group devops to the group in the config but I think that's failing and I don't get why
so LONG story short I got this working using the following config.
#!../../../sbin/tac_plus
id = spawnd {
listen = { port = 49 }
spawn = {
instances min = 1
instances max = 10
}
background = no
}
id = tac_plus {
debug = PACKET AUTHEN AUTHOR MAVIS
access log = /var/log/tac_plus/access.log
accounting log = /var/log/tac_plus/acct.log
authorization log = /var/log/tac_plus/auth.log
mavis module = external {
setenv LDAP_SERVER_TYPE = "microsoft"
#setenv LDAP_HOSTS = "ldaps://xxxxxxxxx:3268"
setenv LDAP_HOSTS = "xxxxxxxxx:3268"
#setenv LDAP_SCOPE = sub
setenv LDAP_BASE = "cn=Users,dc=nskope,dc=net"
setenv LDAP_FILTER = "(&(objectclass=user)(sAMAccountName=%s))"
setenv LDAP_USER = "xxxxxxxx"
setenv LDAP_PASSWD = "xxxxxxxx"
#setenv FLAG_FALLTHROUGH=1
setenv UNLIMIT_AD_GROUP_MEMBERSHIP = "1"
#setenv EXPAND_AD_GROUP_MEMBERSHIP=1
#setenv FLAG_USE_MEMBEROF = 1
setenv AD_GROUP_PREFIX = ""
# setenv REQUIRE_AD_GROUP_PREFIX = 1
# setenv USE_TLS = 0
exec = /usr/local/lib/mavis/mavis_tacplus_ldap.pl
}
user backend = mavis
login backend = mavis
pap backend = mavis
skip missing groups = yes
host = world {
address = 0.0.0/0
#prompt = "Welcome\n"
key = cisco
}
group = devops {
default service = permit
service = shell {
default command = permit
default attribute = permit
set priv-lvl = 15
}
}
}
what really did the trick is adding
setenv UNLIMIT_AD_GROUP_MEMBERSHIP = "1"
setenv AD_GROUP_PREFIX = ""
with these settings it's not looking for a prefix to the all the ad groups. This config allows for a direct mappings of ad group to the group configured in this file, in my case the group is called dev ops. also note that I had to use quotes around the 1. without these quests it does not set the var UNLIMIT_AD_GROUP_MEMBERSHIP to one so watch out for that. hopefully this can help someone else so they do not have to go through all the pain I did ;)
I'm using xdebug to analysis my website performance .
here is my php.ini config informations:
zend_extension = "C:\xampp\php\ext\php_xdebug.dll";
xdebug.remote_enable = true;
xdebug.remote_host = 127.0.0.1;
xdebug.remote_port = 9000 ;
xdebug.profiler_enable = on;
xdebug.trace_output_dir = "C:\xdebug\trace";
xdebug.profiler_output_dir = "C:\xdebug\profiler";
xdebug.auto_trace = On;
xdebug.show_exception_trace = On;
xdebug.remote_autostart = On;
xdebug.collect_vars = On;
xdebug.collect_return = On;
xdebug.collect_params = On;
xdebug.show_local_vars = On;
xdebug.default_enable = On;
xdebug.remote_handler = dbgp;
xdebug.max_nesting_level = 10000;
In this situation, I can link phpstrom 9.0 to debug my PHP application .
But when I want to collect trace data in local file, apache will return http 502 error to browser and I don't know why this happen.
I am stuck with a problem that happens sometimes around unixODBC and freeTDS. I have a CentOS webserver where I have settled configuration files as:
odbc.ini:
[XYZ]
Driver = FreeTDS
Server = X.X.X.X
Port = 1433
Database = mydatabase
TDS_Version = 8.0
odbcinst.ini
[PostgreSQL]
Description = ODBC for PostgreSQL
Driver = /usr/lib/libodbcpsql.so
Setup = /usr/lib/libodbcpsqlS.so
FileUsage = 1
[FreeTDS]
Description = v0.82 with protocol v8.0
Driver = /usr/local/lib/libtdsodbc.so
Setup = /usr/local/lib/libtdsodbc.so
UsageCount = 1
Trace = Yes
TraceFile = /tmp/freetds.log
ForceTrace = Yes
FileUsage = 1
[ODBC]
;Trace = Yes
;TraceFile = /tmp/freetds.log
;ForceTrace = Yes
;Pooling = No
freetds.conf
# $Id: freetds.conf,v 1.12 2007/12/25 06:02:36 jklowden Exp $
#
# This file is installed by FreeTDS if no file by the same
# name is found in the installation directory.
#
# For information about the layout of this file and its settings,
# see the freetds.conf manpage "man freetds.conf".
# Global settings are overridden by those in a database
# server specific section
[global]
# TDS protocol version
tds version = 8.0
# Whether to write a TDSDUMP file for diagnostic purposes
# (setting this to /tmp is insecure on a multi-user system)
; dump file = /tmp/freetds.log
; debug flags = 0xffff
# Command and connection timeouts
; timeout = 10
; connect timeout = 10
# If you get out-of-memory errors, it may mean that your client
# is trying to allocate a huge buffer for a TEXT field.
# Try setting 'text size' to a more reasonable limit
text size = 64512
# A typical Sybase server
[egServer50]
host = symachine.domain.com
port = 5000
tds version = 5.0
# A typical Microsoft server
[egServer70]
host = ntmachine.domain.com
port = 1433
tds version = 7.0
[XYZ]
host = X.X.X.X
port = 1433
tds version = 8.0
and doing isql -v XYZ username password when it won't connect it gives out this trace log:
[ODBC][22870][__handles.c][444]
Exit:[SQL_SUCCESS]
Environment = 0x938ab58
[ODBC][22870][SQLAllocHandle.c][345]
Entry:
Handle Type = 2
Input Handle = 0x938ab58
[ODBC][22870][SQLAllocHandle.c][463]
Exit:[SQL_SUCCESS]
Output Handle = 0x938b130
[ODBC][22870][SQLConnect.c][3549]
Entry:
Connection = 0x938b130
Server Name = [XYZ][length = 14 (SQL_NTS)]
User Name = [username][length = 11 (SQL_NTS)]
Authentication = [*************][length = 13 (SQL_NTS)]
UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'
DIAG [42000] [FreeTDS][SQL Server]Login failed for user 'username'.
DIAG [42000] [FreeTDS][SQL Server]Cannot open database "mydatabase" requested by the login. The login failed.
DIAG [S1000] [FreeTDS][SQL Server]Unable to connect to data source
[ODBC][22870][SQLConnect.c][3917]
Exit:[SQL_ERROR]
[ODBC][22870][SQLError.c][424]
Entry:
Connection = 0x938b130
SQLState = 0xbf8ba54e
Native = 0xbf8ba350
Message Text = 0xbf8ba359
Buffer Length = 500
Text Len Ptr = 0xbf8ba356
[ODBC][22870][SQLError.c][461]
Exit:[SQL_SUCCESS]
SQLState = S1000
Native = 0xbf8ba350 -> 0
Message Text = [[unixODBC][FreeTDS][SQL Server]Unable to connect to data source]
[ODBC][22870][SQLError.c][424]
Entry:
Connection = 0x938b130
SQLState = 0xbf8ba54e
Native = 0xbf8ba350
Message Text = 0xbf8ba359
Buffer Length = 500
Text Len Ptr = 0xbf8ba356
[ODBC][22870][SQLError.c][461]
Exit:[SQL_SUCCESS]
SQLState = 37000
Native = 0xbf8ba350 -> 4060
Message Text = [[unixODBC][FreeTDS][SQL Server]Cannot open database "mydatabase" requested by the login. The login failed.]
[ODBC][22870][SQLError.c][424]
Entry:
Connection = 0x938b130
SQLState = 0xbf8ba54e
Native = 0xbf8ba350
Message Text = 0xbf8ba359
Buffer Length = 500
Text Len Ptr = 0xbf8ba356
[ODBC][22870][SQLError.c][461]
Exit:[SQL_SUCCESS]
SQLState = 37000
Native = 0xbf8ba350 -> 18456
Message Text = [[unixODBC][FreeTDS][SQL Server]Login failed for user 'username'.]
[ODBC][22870][SQLError.c][424]
Entry:
Connection = 0x938b130
SQLState = 0xbf8ba54e
Native = 0xbf8ba350
Message Text = 0xbf8ba359
Buffer Length = 500
Text Len Ptr = 0xbf8ba356
[ODBC][22870][SQLError.c][461]
Exit:[SQL_NO_DATA]
[ODBC][22870][SQLError.c][504]
Entry:
Environment = 0x938ab58
SQLState = 0xbf8ba54e
Native = 0xbf8ba350
Message Text = 0xbf8ba359
Buffer Length = 500
Text Len Ptr = 0xbf8ba356
[ODBC][22870][SQLError.c][541]
Exit:[SQL_NO_DATA]
[ODBC][22870][SQLFreeHandle.c][268]
Entry:
Handle Type = 2
Input Handle = 0x938b130
[ODBC][22870][SQLFreeHandle.c][317]
Exit:[SQL_SUCCESS]
[ODBC][22870][SQLFreeHandle.c][203]
Entry:
Handle Type = 1
Input Handle = 0x938ab58
when tsql command works... what could be?
unixODBC version is 2.2.11-7.1 and freeTDS doesn't appear as installed but it there is since there are present libtdsodbc.so in /usr/local/lib..
I have also to say only with a complete reboot of CentOS machine isql goes back working well...
What I can do or check? Thanks a lot in advance!
Cheers,
Luigi
you should fix odbc.ini to have a servername as configured at freetds.conf
instead of "Server = x.x.x.x" put "servername = XYZ"