For some unknown reason (not even in Redis log), this piece of code will stuck forever... Please help..
use v6;
use Redis;
my $redis = Redis.new("127.0.0.1:6379");
$redis.auth("xxxxxxxxx");
$redis.set("key", "value");
say $redis.get("key");
say $redis.info();
$redis.quit();
I wonder if the issue is because the Redis library is a bit old and there's been a few changes to the runtime in the intervening time.
Have you tried Redis::Async? It seems more up to date.
Related
Is there a way to make the logged user (on superset) to make the queries on impala?
I tried to enable the "Impersonate the logged on user" option on Databases but with no success because all the queries run on impala with superset user.
I'm trying to achieve the same! This will not completely answer this question since it does not still work but I want to share my research in order to maybe help another soul that is trying to use this instrument outside very basic use cases.
I went deep in the code and I found out that impersonation is not implemented for Impala. So you cannot achieve this from the UI. I found out this PR https://github.com/apache/superset/pull/4699 that for whatever reason was never merged into the codebase and tried to copy&paste code in my Superset version (1.1.0) but it didn't work. Adding some logs I can see that the configuration with the impersonation is updated, but then the actual Impala query is with the user I used to start the process.
As you can imagine, I am a complete noob at this. However I found out that the impersonation thing happens when you create a cursor and there is a constructor parameter in which you can pass the impersonation configuration.
I managed to correctly (at least to my understanding) implement impersonation for the SQL lab part.
In the sql_lab.py class you have to add in the execute_sql_statements method the following lines
with closing(engine.raw_connection()) as conn:
# closing the connection closes the cursor as well
cursor = conn.cursor(**database.cursor_kwargs)
where cursor_kwargs is defined in db_engine_specs/impala.py as the following
#classmethod
def get_configuration_for_impersonation(cls, uri, impersonate_user, username):
logger.info(
'Passing Impala execution_options.cursor_configuration for impersonation')
return {'execution_options': {
'cursor_configuration': {'impala.doas.user': username}}}
#classmethod
def get_cursor_configuration_for_impersonation(cls, uri, impersonate_user,
username):
logger.debug('Passing Impala cursor configuration for impersonation')
return {'configuration': {'impala.doas.user': username}}
Finally, in models/core.py you have to add the following bit in the get_sqla_engine def
params = extra.get("engine_params", {}) # that was already there just for you to find out the line
self.cursor_kwargs = self.db_engine_spec.get_cursor_configuration_for_impersonation(
str(url), self.impersonate_user, effective_username) # this is the line I added
...
params.update(self.get_encrypted_extra()) # already there
#new stuff
configuration = {}
configuration.update(
self.db_engine_spec.get_configuration_for_impersonation(
str(url),
self.impersonate_user,
effective_username))
if configuration:
params.update(configuration)
As you can see I just shamelessy pasted the code from the PR. However this kind of works only for the SQL lab as I already said. For the dashboards there is an entirely different way of querying Impala that I did not still find out.
This means that queries for the dashboards are handled in a different way and there isn't something like this
with closing(engine.raw_connection()) as conn:
# closing the connection closes the cursor as well
cursor = conn.cursor(**database.cursor_kwargs)
My gut (and debugging) feeling is that you need to first understand the sqlalchemy part and extend a new ImpalaEngine class that uses a custom cursor with the impersonation conf. Or something like that, however it is not simple (if we want to call this simple) as the sql_lab part. So, the trick is to find out where the query is executed and create a cursor with the impersonation configuration. Easy, isnt'it ?
I hope that this could shed some light to you and the others that have this issue. Let me know if you did find out another way to solve this issue, or if this comment was useful.
Update: something really useful
A colleague of mine succesfully implemented impersonation with impala without touching any superset related, but instead working directly with the impyla lib. A PR was open with the code to change. You can apply the patch directly in the impyla src used by superset. You have to edit both dbapi.py and hiveserver2.py.
As a reminder: we are still testing this and we do not know if it works with different accounts using the same superset instance.
I need to set variables in root scope in one job to be used in a different job. The first job has a Javascript job entry, with the statements:
parent_job.setVariable("customers_full_path", "C:\\customers22.csv", "r");
true;
But the compilation fails with:
Couldn't compile javascript:
org.mozilla.javascript.EvaluatorException: Can't find method
org.pentaho.di.job.Job.setVariable(string,string,string). (#2)
How to set a variable at root level in a Javascript job entry?
Sorry for the passive agressive but:
I don't know if you are new to Pentaho but, the most common mistake for new users, with previous knowledge of programming, is to be sort of 'addicted' to know methods, as such you are using JavaScript for a functionality that is built in the tool. Both Transformations(KTR) and JOBs(KJB) have a similar step, you can better manipulate this in a KTR.
JavaScript steps slow down the flow considerably, so try to stay away from those as much as possible.
EDIT:
Reading This article, seems the only thing you're doing wrong is the actual syntax of the command..
Correct usage :
parent_job.setVariable("Desired Value", [name_of_variable]);
The command you described has 3 parameters, when it should be 2. If you have more than 1 variable you need to set, use 3 times the command. Try it out see if it works.
I'm looking for a variable that can tell me which number 'won' the call on a multi-target Dial command.
Example:
Dial(SIP/1000&SIP/1001&SIP/1002,30)
Set(the_unlucky_winner=${...})
I'm not getting anything from the ${DIALEDPEERx} variables. Sounds like these vars are broken but I don't know if this is what I should be using.
Ancient version 1.2.14 deployed at this site. All clients are SIP
Thanks anyone
Only realistic way do that - cal via Local channle like freepbx do(check freepbx.org source) or use Macro on answer(i am afraid not work in 1.2)
Parse the contents of the CDR record for the file. One of the fields is dstchannel which will hold a value like SIP/1002-9786b0b0.
Also keep in mind that the call variable stack is wiped on hangup, unless you have an "h" (hangup) extension defined for the context. So, you can most easily handle your post-call processing there.
Further Reading:
http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/asterisk-SysAdmin-SECT-1.html
Please Note:
if this answer turns out to solve your problem, please "accept" it for the benefit of others trying to solve the same problem later
Hi all I have a solution to this problem. It is working fine for both normal dial and multi target dial.
In dialstring add a macro, here I am adding "followme" macro.
M(followme)
$agi->exec("dial", "SIP/6001#sip.example.com&SIP/6002#sip.example.com,rtTgM(followme)");
Then after call is answered it ll go to context
[macro-followme]
In this context you write one script to get the connected calls information by
$dstchannel=$agi->get_variable("DIALEDPEERNUMBER");
The way I managed to do it is as follows
Dial(SIP/1000&SIP/1001&SIP/1002,30,M(whoanswered))
[macro-whoanswered]
exten => s,1,NoOp(${CHANNEL})
You will see that the actual extension that answered is containes in ${CHANNEL}
If 1001 answered the channel will be something like SIP/1001-00017cf1
Just use the CUT command to cut it by / and -
I am trying to figure out a way to get the below code work; I have tried various methods but the chef-client run breaks at the 3rd line.
lsf = "#{node[:env]}"+"_ls"
dsf = "#{node[:env]}"+"_ds"
dsTemplateBag = data_bag_item('configTemplates', "#{dsf}")
lcTemplateBag = data_bag_item('configTemplates', "#{lsf}")
However on another test recipe I was able to successfully get the following working:
env = "test"
dsTemplateBag = data_bag_item('configTemplates', "#{env}")
I am quite new to Chef and please can someone advise me on how to get this working ?
After a little bit debugging I realised there was a typo preventing the data bag to be properly used; hence issue.
dsTemplateBag = data_bag_item('configTemplates', "#{node[:env]}_ls")
this worked for me. And as Tensibai suggested in the above comment mixing concatenation and interpolation is not a good practice (I was desperate to make it work! In my defense).
Is there a way to clear Redis shell (Redis-cli) from the output of the previous commands?
Basically I need completely the same action like I have answered in this question, but instead MongoDB I need it for Redis.
P.S. I tried clc, cls, clear, CTR + L but as you understood with no results.
On terminals supported by Linenoise (used in redis-cli), both clear and CTRL-L work fine. It does with my ssh connection. Linenoise implements clear screen in the following way:
void linenoiseClearScreen(void) {
if (write(STDIN_FILENO,"\x1b[H\x1b[2J",7) <= 0) {
/* nothing to do, just to avoid warning. */
}
}
So I guess this sequence does not work on your terminal ... or perhaps, you are using a very old version of redis-cli?