tgoogleanalytics stops working in talend - google-analytics

I am using the tgoogleanalytics version 6.1 in Talend 6.3. I fill in the details in the component. I also give the location of the client_secret.json
However, I get the following error and it gets stuck until I kill it manually:
Starting job counts at 15:28 03/02/2017.
[statistics] connecting to socket on port 3719
[statistics] connected
2017-02-03 15:28:53.497:INFO::Logging to STDERR via org.mortbay.log.StdErrLog
2017-02-03 15:28:53.498:INFO::jetty-6.1.x
2017-02-03 15:28:53.512:INFO::Started SocketConnector#localhost:39096
Please open the following address in your browser:
https://accounts.google.com/o/oauth2/auth?client_id=174006231113-mpd4dqr61uhm6rlvbhdma8o0791mv8g5.apps.googleusercontent.com&redirect_uri=http://localhost:39096/Callback&response_type=code&scope=https://www.googleapis.com/auth/analytics.readonly

Related

PhpUnit not executing via PhpStorm remote interpreter in Docker

The issue I've got is that PhpUnit does not function (properly, something does happen) when just plain clicking "Run" (Shift + F10 on Windows) in PhpStorm.
First up, followed tutorials/setup guides:
https://blog.jetbrains.com/phpstorm/2016/11/docker-remote-interpreters/
https://blog.alejandrocelaya.com/2017/02/01/run-phpunit-tests-inside-docker-container-from-phpstorm/
https://stackoverflow.com/a/47578104
So now, pretty much got a working setup, apart from it doesn't.
Testing started at 15:21 ...
[docker://IMAGE_NAME:latest/]:php bin/.phpunit/phpunit-6.5/phpunit --configuration /var/www/html/phpunit.xml.dist --teamcity
PHPUnit 6.5.14 by Sebastian Bergmann and contributors.
Testing Project Test Suite
Fatal error: Uncaught PDOException: SQLSTATE[HYT00]: [unixODBC][Microsoft][ODBC Driver 17 for SQL Server]Login timeout expired in /var/www/html/src/Legacy/Connection/MssqlConnection.php on line 178
PDOException: SQLSTATE[HYT00]: [unixODBC][Microsoft][ODBC Driver 17 for SQL Server]Login timeout expired in /var/www/html/src/Legacy/Connection/MssqlConnection.php on line 178
Call Stack:
0.0003 393408 1. {main}() /var/www/html/bin/.phpunit/phpunit-6.5/phpunit:0
0.0571 923544 2. PHPUnit\TextUI\Command::main() /var/www/html/bin/.phpunit/phpunit-6.5/phpunit:17
0.0571 923656 3. Symfony\Bridge\PhpUnit\Legacy\CommandForV6->run() /var/www/html/bin/.phpunit/phpunit-6.5/src/TextUI/Command.php:148
0.2019 4269152 4. Symfony\Bridge\PhpUnit\Legacy\TestRunnerForV6->doRun() /var/www/html/bin/.phpunit/phpunit-6.5/src/TextUI/Command.php:195
0.2158 4697272 5. PHPUnit\Framework\TestSuite->run() /var/www/html/bin/.phpunit/phpunit-6.5/src/TextUI/TestRunner.php:545
0.2181 4702968 6. PHPUnit\Framework\TestResult->startTestSuite() /var/www/html/bin/.phpunit/phpunit-6.5/src/Framework/TestSuite.php:689
0.2233 4717824 7. App\Tests\Helper\DeleteDBOnceListener->startTestSuite() /var/www/html/bin/.phpunit/phpunit-6.5/src/Framework/TestResult.php:368
0.2270 4739216 8. App\Legacy\Connection\MssqlConnection->databaseExists() /var/www/html/tests/Helper/DeleteDBOnceListener.php:55
0.2270 4739216 9. App\Legacy\Connection\MssqlConnection->findDbFromDSN() /var/www/html/src/Legacy/Connection/MssqlConnection.php:38
0.2271 4740104 10. PDO->__construct() /var/www/html/src/Legacy/Connection/MssqlConnection.php:178
Process finished with exit code 255
Obviously this reads as: cannot connect to DB. But!
If I log into the Docker instance, and then run the command, it works! Command:
php bin/.phpunit/phpunit-6.5/phpunit --configuration /var/www/html/phpunit.xml.dist
Generates output:
user#hash:/var/www/html# php bin/.phpunit/phpunit-6.5/phpunit --configuration /var/www/html/phpunit.xml.dist
PHPUnit 6.5.14 by Sebastian Bergmann and contributors.
Testing Project Test Suite
Dropping current database...
.Creating database..
................................................................ 65 / 80 ( 81%)
............... 80 / 80 (100%)
Time: 3.25 minutes, Memory: 56.12MB
OK (80 tests, 336 assertions)
So why, when executing using "Run", does this fail when doing it from PhpStorm? Did I miss a setting?
Since you asked your question 3 years ago you probably also answered it yourself. However I will leave my answer for people who enter here in future.
The error HYT00 is a timeout error from MSSQL client. This basically means that your client does not have access to the server (or that it responding very slow).
If you configure PHPStorm to use the docker container as an interpreter it's doing exactly this - only using the PHP you have inside the docker container as an interpreter but not running it inside of the container. You are still running it in your host environment, in your host network etc.
Make sure you have access to the database from your host machine and that you are using a correct connection string while running the tests. In your test configuration you may have the internal hostnames of docker (between docker containers you may for example use container names as their hostnames). When running from the host machine you will need an accessible hsotname, like localhost:1433 if you have the ports mapped to host machine.
With this checked the tests should execute correctly.
Just an offtopic - unless you are doing integration tests it's not a good idea to connect to SQL in Unit tests. Better to use mocks:)

OpenVAS: OSPD scanner can't be used as scanner in new task

After understanding how to add an ospd scanner, verify it etc ...
I though I could finally use it but got an error through UI to add it to a task.
In my case, I run OpenVAS 9 on a debian 9 and I'm trying to include a w3af scanner but I got the same issue with every OSP scanner I add.
my pip freeze :
ospd==1.2.0
ospd-debsecan==1.2b1
ospd-nmap==1.0b1
ospd-w3af==1.0.0
Note that here is an example of w3af but the issue is the same for debsecan scanner and nmap scanner.
my openvas-check-setup :
Step 1: Checking OpenVAS Scanner ...
OK: OpenVAS Scanner is present in version 5.1.1.
OK: redis-server is present in version v=3.2.6.
OK: scanner (kb_location setting) is configured properly using the redis-server socket: /tmp/redis.sock
OK: redis-server is running and listening on socket: /tmp/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: NVT collection in /usr/local/var/lib/openvas/plugins contains 47727 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
SUGGEST: Enable signature checking (see http://www.openvas.org/trusted-nvts.html).
OK: The NVT cache in /usr/local/var/cache/openvas contains 47727 files for 47727 NVTs.
Step 2: Checking OpenVAS Manager ...
OK: OpenVAS Manager is present in version 7.0.2.
OK: OpenVAS Manager database found in /usr/local/var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
OK: OpenVAS Manager database is at revision 184.
OK: OpenVAS Manager expects database at revision 184.
OK: Database schema is up to date.
OK: OpenVAS Manager database contains information about 47727 NVTs.
OK: At least one user exists.
OK: OpenVAS SCAP database found in /usr/local/var/lib/openvas/scap-data/scap.db.
OK: OpenVAS CERT database found in /usr/local/var/lib/openvas/cert-data/cert.db.
OK: xsltproc found.
Step 3: Checking user configuration ...
WARNING: Your password policy is empty.
SUGGEST: Edit the /usr/local/etc/openvas/pwpolicy.conf file to set a password policy.
Step 4: Checking Greenbone Security Assistant (GSA) ...
OK: Greenbone Security Assistant is present in version 7.0.2.
OK: Your OpenVAS certificate infrastructure passed validation.
Step 5: Checking OpenVAS CLI ...
OK: OpenVAS CLI version 1.4.5.
Step 6: Checking Greenbone Security Desktop (GSD) ...
SKIP: Skipping check for Greenbone Security Desktop.
Step 7: Checking if OpenVAS services are up and running ...
OK: netstat found, extended checks of the OpenVAS services enabled.
OK: OpenVAS Scanner is running and listening on a Unix domain socket.
OK: OpenVAS Manager is running and listening on a Unix domain socket.
OK: Greenbone Security Assistant is listening on port 443, which is the default port.
Step 8: Checking nmap installation ...
WARNING: Your version of nmap is not fully supported: 7.40
SUGGEST: You should install nmap 5.51 if you plan to use the nmap NSE NVTs.
Step 10: Checking presence of optional tools ...
OK: pdflatex found.
WARNING: PDF generation failed, most likely due to missing LaTeX packages. The PDF report format will not work.
SUGGEST: Install required LaTeX packages.
OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
OK: rpm found, LSC credential package generation for RPM based targets is likely to work.
OK: alien found, LSC credential package generation for DEB based targets is likely to work.
OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.
To create the scanner in openvas, I use:
openvasmd --create-scanner="w3af" --scanner-host=127.0.0.1 --scanner-port=1235 --scanner-type="OSP" \
--scanner-ca-pub=/usr/local/var/lib/openvas/CA/cacert.pem \
--scanner-key-pub=/usr/local/var/lib/openvas/CA/clientcert.pem \
--scanner-key-priv=/usr/local/var/lib/openvas/private/CA/clientkey.pem
To run ospd-w3af scanner, I use:
~# ospd-w3af -b 127.0.0.1 -p 1235 -k \
/usr/local/var/lib/openvas/private/CA/clientkey.pem -c \
/usr/local/var/lib/openvas/CA/clientcert.pem --ca-file \
/usr/local/var/lib/openvas/CA/cacert.pem -L DEBUG
When I verify the scanner with openvasmd --verify-scanner xxxxx I got
Scanner version: 2018.8.22.
note: in the logs of the scanner I got this for every verify I do, I don't know if it's related or no and I didn't find a way to fix this:
2018-10-15 14:27:47,413 ospd.ospd: DEBUG: New connection from 127.0.0.1:60078
2018-10-15 14:27:49,430 ospd.ospd: DEBUG: Error: ('The read operation timed out',)
2018-10-15 14:27:49,433 ospd.ospd: DEBUG: 127.0.0.1:60078: Connection closed
So, my verification made, I want to create a task that uses this scanner but I can't save it due to error "Given scanner_type was invalid" :
https://i.stack.imgur.com/fvIJd.png
I got 0 connection to the chosen scanner at this moment and I can't find anything in the logs (maybe I can't search). I suspect the gsad UI being responsible for this but I can't find it.
I don't know what to do and if someone more expert than me (not very hard) could help that'd be great :)
Thanks in advance.
I solved this issue by creating a scan configuration for the ospd scanner (I though it didn't need one since it import them)
I faced another issue concerning ospd-w3af configuration, I couldn't create one because it needs ospd 1.0.0 installed, I modified the dependencies few days ago and it doesn't work with ospd 1.2.0
Now I'm facing the issue where the scans doesn't start properly. It stops at 1%
Getting openvas 9 running on new install of Ubuntu 18 was a pain. once i got past all my errors by creating files and ln -s for redis-server socks connections my tasks crapped out at 1%. My fix was install sudo apt install libopenvas-dev after that scans work and check-setup worked. Check-setup report no scanner but openvassd was running and openvasmd --verify-scanner (uuid) showed the scanner.

How to make a client / server connection using Rserver and Windows Server 2008

I am searching for a robust solution to perform extensive computations on a remote server, dedicated to computational tasks. The server is on Windows 2008 R2 and has R x64 3.4.1 installed on it. I've searched for free solutions and am now focusing on the Rserver/RSclient packages solutions.
However, I can't connect any client (using RSclient) to the instanced server.
This is how I'm proceeding at the moment from the server side:
library(Rserve)
run.Rserve(config.file = "Rserv.conf")
using the following Rserv.conf file:
port 6311
remote enable
plaintext enable
control enable
r-control enable
The server is now intanciated using the Rsession (It's a bit ugly, but will change that latter on):
running Rserve in this R session (pid=...), 1 server(s)
Now, i'm trying to connect using a remote computer (Client-side) using:
library(RSclient)
c = RS.connect(host = "...")
The connection then seems to succeed, checking for c:
> c
Rserve QAP1 connection 0x000000000fbe9f50 (socket 764, queue length 0)
The error occurs when i try to eval anything, for example:
> RS.server.eval(c,"0<1")
Error in RS.server.eval(c, "0<1") : command failed with status code 0x4e: no control line present (control commands disabled or server shutdown)
I've read the available guides but still failed in connecting. What is wrong? It seems to be related to control lines but I authorized them in the config file.
for me the problem was solved by initiating the Rserve instance with the command:
R CMD Rserve --RS-port 9000 --RS-enable-remote --RS-enable-control
instead of starting it in the R environment (library(Rserve), run.Rserve(config.file = "Rserv.conf")). You may try this on Windows as well.
Refer https://github.com/s-u/Rserve/wiki/rserve.conf.
port 6311
remote enable -> it should be remote true
plaintext enable
control enable
r-control enable
Likewise refer the link and try with actual values

Command died with signal 6: "/usr/libexec/dovecot/deliver

Emails are not being deliver to a particular email IDs.
We are using Sentora panel and Postfix mail server.
Error message:
Command died with signal 6: "/usr/libexec/dovecot/deliver"
Mail log:
Feb 14 09:50:27 host postfix/pipe[24913]: CBD7D2010A5: to=,
relay=dovecot, delay=13047, delays=13045/0/0/1.3, dsn=4.3.0,
status=SOFTBOUNCE (Command died with signal 6:
"/usr/libexec/dovecot/deliver")
Please help.
Signal 6 is SIGABRT, which is typically sent when there is an internal problem with the code of Dovecot's deliver binary. There are a number of reasons this could happen.
You can turn on LDA logging within your Dovecot config to get more insight on what's actually happening:
protocol lda {
...
# remember to give proper permissions for these files as well
log_path = /var/log/dovecot-lda-errors.log
info_log_path = /var/log/dovecot-lda.log
}
this can also happen when mail_temp_dir (default: /tmp) does not have enough space to extract attachments. it was fixed in https://github.com/dovecot/core/commit/43d7f354c44b358f45ddd10deb3742ec1cc94889 but is not yet available in some linux distributions (such as debian bullseye).

HAAst terminating with exit code 158

I'm just trying to do a POC test with Telium's HAAst before we offer it to a customer, but I've stalled before I start the haast daemon. Currently I have a single VM with Ubuntu 16.04 LTS with Digium's basic Asterisk 13 installation. I've configured haast.conf, it seems good, but I cannot start haast daemon, it stops after a few seconds. Here is the relevant log output:
General, HAAst version 2.3.2.1 starting as daemon under process ID 2409
Controller, Local peer HAAst state changing to service start
License, License file not found. Switching to Free Edition
General, Settings contained 0 information; 0 warning; and 0 error messages.
Asterisk Controller, Unable to located executable to control Asterisk
Controller, Local peer HAAst state changing to service stop
Controller, Stopped
General, HAAst terminating with exit code 158 (failure to find asterisk control files) after running for 2 seconds
It seems, haast misses the event controller to start Asterisk daemon, unfortunately it didn't contain the installation package. I've tried to make these files (asterisk.start & asterisk.stop) based on the other sample event files, I've set the executable bit, I've wrote the shebang to the first line based on the installation guide, but nothing helped.
Is somebody experienced about this case?
Thanks, Zsolt
This error means that High Availability for Asterisk (HAAst) is unable to find the service/executable file needed to control Asterisk. Since the 'distribution' setting in the [asterisk] stanza of the haast.conf file is it to 2 (Digium Asterisk), it means there's a problem with the Asterisk service file.
Ubuntu 16 uses systemd so have you installed Digium's asterisk.service (systemd) file? If you chose to install an initd service file for Asterisk instead then you may have to explicitly tell HAAst which to look for. If you installed neither then that's your problem. The maker of HAAst (Telium) has a support forum where this topic is addressed (click here).
The pre and post Asterisk event handlers are available in the commercial versions of HAAst only - so that won't help (but it's also the wrong way to solve the problem). There are also a few Ubuntu specific topics on the support forum https://www.telium.io/haast in case that helps.
If you can't find an Asterisk systemd service file here's a sample:
[Unit]
Description=Asterisk PBX and telephony daemon
Documentation=man:asterisk(8)
Wants=network.target
After=network.target
[Service]
Type=simple
User=asterisk
Group=asterisk
ExecStart=/usr/bin/asterisk -f -C /etc/asterisk/asterisk.conf
ExecStop=/usr/bin/asterisk -rx 'core stop now'
ExecReload=/usr/bin/asterisk -rx 'core reload'
[Install]
WantedBy=multi-user.target
Just save that file as 'asterisk.service' and place in /etc/systemd/system/ and ensure permissions match other service/unit files.
Haast configuration is missing or not correct:
Unable to located executable to control Asterisk

Resources