I just put my project from localhost to my host and using the same (phpass) function I receive different results and the length of the returned string is also different. (and everything works on localhost.)
Here's the result:
Input: 12345
host:$2a$08$t5joFUIbEThylj/IyUVy7.WzMZm8fmKjsy0kZc/YxgqzkbYQWnlre
localhost: $P$9QiKVfJzpRzoToBCJg8FeaDIfcAJJ61
I was wondering what the problem might be.
thanks for all suggest and answer.
Related
I have this Analysis that I wish to invoke from URL (which I can).
This analysis in particular is mounted on a dashboard and 6 of the 17 columns can be filtered from a prompt mounted on the same dashboard.
I only need the analysis and still be able to filter the results. I read about parameters that can be given to the URL, but I can't seem to make the filters work. I am using the &P0=n parameter and the consequent &P1=xx parameter.
Without the &P I am able to see the table, when I add parameters I get this error UH6MBRBC:E6MUPJPH.
Thanks for your time, have a nice day.
Got it to work by myself afterall (always best).
Basically instead of &p0 and such I used &coln and &valn (where n is the column number):
&coln - is the name of the field
&valn - is the value for which you filter
More information and better explanation can be found here.
I have an object, which pprints into:
#<OpenSSL::ASN1::ASN1Data:0x0000000803ab37a8
#infinite_length=false,
#tag=7,
#tag_class=:CONTEXT_SPECIFIC,
#value="\x7F\x00\x00\x01">]>
It is easy enough to see, that the #value is an IP-address: 127.0.0.1. How do I reliably extract it, however -- so that it works regardless of endianness and other hard-to-test considerations?
I'm doing it the following way for now:
ip = v.value.split('').map {|octet| octet.ord }.join('.')
and it works on my machine, but I wonder, how reliable the method is...
Ok, as I report in a related question, I found an answer in Ruby's own code (openssl/ssl.rb). They deal with both IPv4 and IPv6 addresses thus -- using unpack instead of split-ing the string into characters:
case v.value.size
when 4
ip = v.value.unpack('C*').join('.')
when 16
ip = v.value.unpack('n*').map { |o| sprintf("%X", o) }.join(':')
else
STDERR.print "The encountered IP-address is neither IPv4 nor IPv6\n"
next
end
I've been working at implementing a simple serial forking described in the TM module's documentation (the Q values are stored as a priority weight in a mysql table) where my proxy is querying a database to determine to what domain to forward to.
I've verified through extensive use of xlog that a variable I'm using to build the new URI to use with seturi is getting everything correctly. I use an append_branch call in a subsequent while loop iterating over my sql query results, which doesn't have any problems with taking a very similarly formatted parameter. However, when I go to restart Kamailio it simply gripes at me that a string is expected. The line it corresponds to from console is just the seturi call. I've tried casting as a string, but that doesn't seem to be part of 4.4 (or my syntax is wrong).
I've thought about building the URI strings and storing into avp, but I suspect I'd have the same problem.
For reference, this is what I'm doing:
$var(basedest) = "sip:" + $var(number) + "#" + $(dbr(destination=>[0,0]))+ ":" + $var(port);
seturi($var(basedest));
And what it's outputting when trying to load the config:
<core> [cfg.y:3368]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 570, column 9-22: syntax error
<core> [cfg.y:3371]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 570, column 23: bad argument, string expected
Naturally, when I put $var(basedest) in double quotes, it's literally interpreted as a string. Single quotes behave similarly. Is there something I can do to work around this? When I feed it an explicit hardcoded string, it's happy as a can be and the routing works fine. When I try to do something very simple like the above, it gets upset. If possible, I'd like to avoid updating as I initially grabbed Kamailio from the yum repo.
Thanks in advance - this has been bugging me a good while.
Apparently, not a new problem. I ended up finding out what I can do to work around it.
For reference, seturi and $ru pseudo variable refer to the same thing. So basically you'd just do:
$var(mynewru) = "sip:user#domain:5060";
$ru = $var(mynewru);
This would achieve the same thing I was originally attempting to do before based on the TM module's documentation. For serial forking, issuing some number of append_branch calls is fine.
When running in parallel I am unable to connect unknowns of subgroups in a ParallelGroup() even though I can connect to the subgroups' params. The code causing the problem (with names changed for clarity) is below. This code is within a group of a larger structure, but is the only place where MPI is being used:
for i in range(0, nTasks):
self.connect('comp_a.output%i' % i, 'parallel_group.sub_group%i.param_a' % i)
self.connect('input_param%i' % i, 'parallel_group.sub_group%i.param_b' % i)
self.connect('parallel_group.sub_group%i.output' % i, 'comp_b.input%i' % i)
The first two connections seem to work fine, but the last one throws an error:
NameError: Source 'parallel_group.sub_group0.output' cannot be connected to target 'comb_b.input0': 'parallel_group.sub_group0.output' does not exist.
Also, if I comment out the offending line, then first line in the loop fails for the second process with the same error message:
NameError: Source 'comp_a.output1' cannot be connected to target 'parallel_group.sub_group1.param_a': 'parallel_group.sub_group1.param_a' does not exist.
All the connections work fine with our serial version of the code. The serial version is the same except that the sub_groups are added directly to the group this code is in rather than being wrapped in parallel_group.
I have tried to look over the tutorials and examples but have not been able to figure what might be wrong. I would really appreciate any suggestions of what to check or what may be wrong. Sorry to not post a complete code sample.
its a little unclear, but it sounds like you've added a new group in the parallel version of the code, named "parallel_group". When you did this, did you promote anything (or everything) from that group? If so, then you shouldn't add the parallel group into the variable name path for the connection.
That seems like the only thing likely to trip you up. I could try to debug a bit more if you can come up with a sample code you can post up here that would show the problem.
I have a source file that contains two fields: IP_ADDRESS and USER_NAME. I want to check whether the IP address is correct or not before loading it to the datawarehouse using DATASTAGE. How do I do this?
I was browsing Stack Overflow and think I might have a solution to your question. If you create a job to grab all of the IP_ADDRESS's from the file and send them to a BASIC transformer (search for BASIC transformer in DataStage. It is NOT the one that is normally on the palette). From there, set the Stage Variables as 'SetUserStatus() and write out the column name to a peek stage (You don't need the output at all. The SetUserStatus is the important part). This will now allow you to pass up the Command Output (list of IP Addresses) to a Sequence. From the Sequence, start with the job you just created (BASIC transformer job) and link that to a User Variables Activity. In the User Variables Activity stage, Set the name to something like 'IP Address' and Expression as IP_ADDRESS.$UserStatus. You can then use a Loop to take that output that is now a List and send each individual IP Address to an Execute Stage with a Ping command to see if it returns a valid IP Address. If it does return a valid IP then have your job that writes the USER_NAME and IP_ADDRESS to do a 'Select' statement where the IP_ADDRESS = the valid IP_ADDRESS. For the ones that aren't valid, you can send them down a different path and have them write out to '.txt' file somewhere so you know which ones weren't valid. I'm sure you will need a few more steps in there but that should be the gist of it.
Hope my quick stab at your issue helps.
Yes, you can use a transformer or a transformer and a filter to do that, depending on the version of Datastage you're using. If you're using PX, just encode the validation logic in a transformer stage, and then, on the output link set up a filter that doesn't allow the rows to pass forward if they didn't pass the validation logic.