the command is below:
cleos set account permission mcdonald active '{"threshold": 1, "keys": [{"key": "EOS7BZwiFi3nyBi9rQJua6wQv37my7G21YYNZo5ZeVKcGZQNFYEjd", "weight": 1}, {"key": "EOS63ZXCNHSAr9ZqXCpAgLNox4CLYZ2u2oCVnNZeVCSp5W82qLb4i", "weight": 1}], "accounts":[{"permission":{"actor":"mcdonald","permission":"active"},"weight":1}, {"permission":{"actor":"mcdonald","permission":"active"},"weight":1}]}' owner
The error message is as follows:
Authority failed validation! ensure that keys, accounts, and waits are
sorted and that the threshold is valid and satisfiable!
What went wrong? I think the format of json should be fine.
try this:
cleos set account permission <your_account> active <contract_account> --add-code
for example:
cleos set account permission me active bob --add-code
cleos set account permission me active alice --add-code
cleos set account permission me active foo --add-code
cleos set account permission me active bar --add-code
then check with cleos get account me
output:
created: 2019-03-01T12:49:08.500
permissions:
owner 1: 1 EOS6MRyXXXXXXXXXcfnVPJqcVpscN5So8BhtXXXXXX
active 1: 1 EOS6MRyXXXXXXXXcfnVPJqcVpscN5So8BhtXXXXXX, 1
alice#eosio.code, 1 bob#eosio.code, 1 foo#eosio.code, 1 bar#eosio.code
memory:
quota: unlimited used: 2.785 KiB
net bandwidth:
used: unlimited
available: unlimited
limit: unlimited
cpu bandwidth:
used: unlimited
available: unlimited
limit: unlimited
Related
I'm running truffle migrate on main. Also using geth.
I originally left gas price and gas empty in truffle.js, but now it looks like this:
live: {
network_id: 1,
host: "127.0.0.1",
port: 8545,
from: "3984bc76cb775d7866d1cd55c4f49e3d13d411d4",
gas: 40000,
gasPrice: 22000000000 // Specified in Wei
}
I seem to have a situation where I either have too much gas or not enough, with no possibility for the right amount.
< {
< "jsonrpc": "2.0",
< "id": 2,
< "error": {
< "code": -32000,
< "message": "insufficient funds for gas * price + value"
< }
< }
Error encountered, bailing. Network state unknown. Review successful transactions manually.
Error: insufficient funds for gas * price + value
...or...
< {
< "jsonrpc": "2.0",
< "id": 2,
< "error": {
< "code": -32000,
< "message": "exceeds block gas limit"
< }
< }
Error encountered, bailing. Network state unknown. Review successful transactions manually.
Error: exceeds block gas limit
When I run web3.eth.getBlock("latest") in console, I get gasLimit: 5000. When I set my gas at 5000 I get the insufficient funds message. When I set it to 5001, I get "exceeds block gas limit".
So, all this seems to be telling me that the gasLimit should be set to 5000 or under 5000, but in that case I don't have sufficient funds to run the transaction. Let's see...
I have:
gas: 5000,
gasPrice: 22000000000 // Specified in Wei
5000 * 22000000000 = 1.1 * 10^14 = 110,000,000,000,000 Wei
1.1 * 10^14 / 10 ^ 18 (number of Wei in 1 Ether) = 1.1*10^-4 ETH
Here's the account I'm using: https://etherscan.io/address/0x3984bc76cb775d7866d1cd55c4f49e3d13d411d4. As you can see, it has funds. 0.01738465 Ether at time of writing, to be precise.
if you are on a test network, on testrpc, the option -l or --gasLimit lets you set the gas available.
On geth, this post should help : https://ethereum.stackexchange.com/questions/13730/how-to-increase-gas-limit-in-block-using-geth
This randomly started working the following day. One thing I noticed was that when I ran web3.eth.getBlock("latest") in truffle console yesterday, I was getting gasLimit: 5000, which was a way lower number than the network was reporting elsewhere. Today I was getting gasLimit: 6706583. I'm really not sure what caused the gas limit to increase locally, but whatever it was seems to have fixed the issue.
I also faced the similar issue. The version of truffle I was using was Truffle v4.0.1 (core: 4.0.1). If you downgrade to beta version things will work just fine.
npm uninstall -g truffle
truffle version(to check if its uninstalled)
npm install -g truffle#beta
You are good to go. This should fix the problem.
I was having the same issue and this is how I made it work:
In truffle console, find out the gas limit for the last block. Use that number in your truffle.js. In my case gas: 4700036 worked.
truffle(development)> web3.eth.getBlock('latest').gasLimit
4700036
To increase the gas limit in Truffle.
which truffle to get location of Truffle
Open in code editor.
code /home/user/.nvm/versions/node/v8.11.1/bin/truffle
currently the limit was set at 6721975so i just searched for this number
crtl+f 6721975 Change it to 8000000 or whatever.
now in truffle develop web3.eth.getBlock('latest') // 8000000
The below VM extension fails to add VM to the domain.
It works fine when the ‘Computer Account’ exists in the AD. If the ‘Computer Account’ do not exist (New Server) it fails.
Set-AzureRmVMADDomainExtension -TypeHandlerVersion '1.0' -JoinOption 3 -DomainName $strDomainDNSName -ResourceGroupName $strRes_GrpName -VMName $strHostName -Credential $objCred -OUPath $strServerOU -Restart
The join option 3 should complete the below actions.
Value Meaning
NETSETUP_JOIN_DOMAIN
0x00000001 Joins the computer to a domain. If this value is not specified, joins the computer to a workgroup.
NETSETUP_ACCT_CREATE
0x00000002 Creates the account on the domain.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370433(v=vs.85).aspx
Found the below error details under Azure VM Extension:
[
{
"code": "ComponentStatus/JoinDomainException for Option 3 meaning 'User Specified'/failed/1",
"displayStatus": "Provisioning failed",
"level": "Error",
"message": "ERROR - Failed to join domain='MyAd.ad.company.co.uk', ou='OU=Computers,DC=MyAd,DC=ad,DC=company,DC=co,DC=uk', user='LocalAdmin#MyAD.ad.company.co.uk', option='NetSetupJoinDomain, NetSetupAcctCreate' (#3 meaning 'User Specified'). Error code 2",
"time": null
}
{
"code": "ComponentStatus/JoinDomainException for Option 1 meaning 'User Specified without NetSetupAcctCreate'/failed/1",
"displayStatus": "Provisioning failed",
"level": "Error",
"message": "ERROR - Failed to join domain='MyAd.ad.company.co.uk', ou='OU=Computers,DC=MyAd,DC=ad,DC=company,DC=co,DC=uk', user='MGTAdmin#MyAd.ad.company.co.uk', option='NetSetupJoinDomain' (#1 meaning 'User Specified without NetSetupAcctCreate'). Error code 1332",
"time": null
}
]
Only the Built-in 'Computers' OU has the problem.
Tried both 'OU=Computers,DC=MyAd,DC=ad,DC=company,DC=co,DC=uk' and 'CN=Computers,DC=MyAd,DC=ad,DC=company,DC=co,DC=uk'. Failed with same Error.
But other user created OU works fine. For Eg. 'OU=TSTVLAN,OU=MGTServers,,DC=MyAd,DC=ad,DC=company,DC=co,DC=uk'
Mine was failing with "User Specified without NetSetupAcctCreate", error 1323 in the logs.
I needed to update the username to include the domain, ie
User= 'domainName\userName'
Then it worked.
Hi am using ejabberd version 16.04 for my chat application and am using mod_rest for creating a muc room and for sending room invitation, now what i need is to set_room_affiliation for a particular mod_muc but its says error could some one help me out please...!!!
Below is the argument am passing for each respective ejabberd commands
Creating a Team
{"key": "secret","command": "create_room","args": ["kandan_team","conference","kandan.com"]}
Team got created. Passed...!!!
For sending Room Invitation to user 1
{"key": "secret","command": "send_direct_invitation","args": ["kandan_team","conference","none", "team_inviataion", "user1#kandan.com"]}
Inviatation sent successfully..!!! Passed..!!!
For sending Room Invitation to user 2
{"key": "secret","command": "send_direct_invitation","args": ["kandan_team","conference","none", "team_inviataion", "user2#kandan.com"]}
Inviatation sent successfully..!!! Passed..!!!
For removing user1 from team
{"key":"secret","command":"set_room_affiliation","args":["kandan_team", "conference", "user1#kandan.com", "outcast"]}
Couldn't remove user1 and saying as error..! Failed..!!!
Ejabberd.yml file configuration for mod_rest
mod_restful:
api:
- path: ["admin"]
module: mod_restful_admin
params:
key: "secret"
allowed_commands: [register, unregister,status, add_rosteritem, create_room, send_direct_invitation, set_room_affiliation]
- path: ["register"]
module: mod_restful_register
params:
key: "secret"
So can someone help me out how to set_room_affiliation please ...!!!
I found the answer, i created muc with wrong service that was the issue.Instead of creating muc with below service i created in other way..!!!
{"key": "secret","command": "create_room","args": ["kandan_team","conference.kandan.com","kandan.com"]}
I've installed (from source) cygnus 0.7.1, and after configuring it (MySQL and HDFS sinks) I can start it without problems. When I subscribe cygnus to a orion context, it receives the information ok, but there is a problem with MySQL and HDFS. This is the log:
15/03/17 13:58:52 INFO handlers.OrionRestHandler: Starting transaction (1426597123-891-0000000000)
15/03/17 13:58:52 INFO handlers.OrionRestHandler: Received data ({ "subscriptionId" : "5508250c1860a36e55240c84", "originator" : "localhost", "contextResponses" : [ { "contextElement" : { "type" : "ubk-temp", "isPattern" : "false", "id" : "ubk:temp:1", "attributes" : [ { "name" : "temperature", "type" : "float", "value" : "11" } ] }, "statusCode" : { "code" : "200", "reasonPhrase" : "OK" } } ]})
15/03/17 13:58:52 INFO handlers.OrionRestHandler: Event put in the channel (id=1549700267, ttl=10)
15/03/17 13:58:52 INFO sinks.OrionSink: Event got from the channel (id=1549700267, headers={fiware-servicepath=ubktemp, destination=ubk_temp_1_ubk-temp, content-type=application/json, fiware-service=ubikwa, ttl=10, transactionId=1426597123-891-0000000000, timestamp=1426597132511}, bodyLength=462)
15/03/17 13:58:52 INFO sinks.OrionSink: Event got from the channel (id=1549700267, headers={fiware-servicepath=ubktemp, destination=ubk_temp_1_ubk-temp, content-type=application/json, fiware-service=ubikwa, ttl=10, transactionId=1426597123-891-0000000000, timestamp=1426597132511}, bodyLength=462)
15/03/17 13:58:52 INFO sinks.OrionMySQLSink: [mysql-sink] Persisting data at OrionMySQLSink. Database: ubikwa, Table: ubktemp_ubk_temp_1_ubk-temp, Timestamp: 2015-03-17T13:58:52.511, Data (attrs): {temperature=11}, (metadata): {temperature_md=[]}
15/03/17 13:58:53 INFO sinks.OrionHDFSSink: [hdfs-sink] Persisting data at OrionHDFSSink. HDFS file (ubikwa/ubktemp/ubk_temp_1_ubk-temp/ubk_temp_1_ubk-temp.txt), Data ({"recvTime":"2015-03-17T13:58:52.511","temperature":"11", "temperature_md":[]})
15/03/17 13:58:53 WARN sinks.OrionSink: Bad context data (Table 'ubikwa.ubktemp_ubk_temp_1_ubk-temp' doesn't exist)
15/03/17 13:58:53 INFO sinks.OrionSink: Finishing transaction (1426597123-891-0000000000)
The MySQL sink does not raise any errors but no tables are created. And the HDFS sink seems to be unable to create the files. I previously installed cygnus 0.6 and it worked with the same configuration.
Edit:
Here its is my configuration:
cygnusagent.sources = http-source
cygnusagent.sinks = hdfs-sink mysql-sink
cygnusagent.channels = hdfs-channel mysql-channel
#=============================================
# source configuration
# channel name where to write the notification events
cygnusagent.sources.http-source.channels = hdfs-channel mysql-channel
# source class, must not be changed
cygnusagent.sources.http-source.type = org.apache.flume.source.http.HTTPSource
# listening port the Flume source will use for receiving incoming notifications
cygnusagent.sources.http-source.port = 5050
# Flume handler that will parse the notifications, must not be changed
cygnusagent.sources.http-source.handler = es.tid.fiware.fiwareconnectors.cygnus.handlers.OrionRestHandler
# URL target
cygnusagent.sources.http-source.handler.notification_target = /notify
# Default service (service semantic depends on the persistence sink)
cygnusagent.sources.http-source.handler.default_service = ubikwa
# Default service path (service path semantic depends on the persistence sink)
cygnusagent.sources.http-source.handler.default_service_path = ubktemp
# Number of channel re-injection retries before a Flume event is definitely discarded (-1 means infinite retries)
cygnusagent.sources.http-source.handler.events_ttl = 10
# Source interceptors, do not change
cygnusagent.sources.http-source.interceptors = ts de
# Timestamp interceptor, do not change
cygnusagent.sources.http-source.interceptors.ts.type = timestamp
# Destination extractor interceptor, do not change
cygnusagent.sources.http-source.interceptors.de.type = es.tid.fiware.fiwareconnectors.cygnus.interceptors.DestinationExtractor$Builder
# Matching table for the destination extractor interceptor, put the right absolute path to the file if necessary
# See the doc/design/interceptors document for more details
cygnusagent.sources.http-source.interceptors.de.matching_table = /opt/cygnus/conf/matching_table.conf
# ============================================
# OrionHDFSSink configuration
# channel name from where to read notification events
cygnusagent.sinks.hdfs-sink.channel = hdfs-channel
# sink class, must not be changed
cygnusagent.sinks.hdfs-sink.type = es.tid.fiware.fiwareconnectors.cygnus.sinks.OrionHDFSSink
# Comma-separated list of FQDN/IP address regarding the Cosmos Namenode endpoints
# If you are using Kerberos authentication, then the usage of FQDNs instead of IP addresses is mandatory
cygnusagent.sinks.hdfs-sink.cosmos_host = 130.206.80.46
# port of the Cosmos service listening for persistence operations; 14000 for httpfs, 50070 for webhdfs and free choice for inifinty
cygnusagent.sinks.hdfs-sink.cosmos_port = 14000
# default username allowed to write in HDFS
cygnusagent.sinks.hdfs-sink.cosmos_default_username = ***
# default password for the default username
cygnusagent.sinks.hdfs-sink.cosmos_default_password = ***
# HDFS backend type (webhdfs, httpfs or infinity)
cygnusagent.sinks.hdfs-sink.hdfs_api = httpfs
# how the attributes are stored, either per row either per column (row, column)
cygnusagent.sinks.hdfs-sink.attr_persistence = column
# Hive FQDN/IP address of the Hive server
cygnusagent.sinks.hdfs-sink.hive_host = 130.206.80.46
# Hive port for Hive external table provisioning
cygnusagent.sinks.hdfs-sink.hive_port = 10000
# Kerberos-based authentication enabling
cygnusagent.sinks.hdfs-sink.krb5_auth = false
# Kerberos username
cygnusagent.sinks.hdfs-sink.krb5_auth.krb5_user = krb5_username
# Kerberos password
cygnusagent.sinks.hdfs-sink.krb5_auth.krb5_password = xxxxxxxxxxxxx
# Kerberos login file
cygnusagent.sinks.hdfs-sink.krb5_auth.krb5_login_conf_file = /usr/cygnus/conf/krb5_login.conf
# Kerberos configuration file
cygnusagent.sinks.hdfs-sink.krb5_auth.krb5_conf_file = /usr/cygnus/conf/krb5.conf
# ============================================
# OrionMySQLSink configuration
# channel name from where to read notification events
cygnusagent.sinks.mysql-sink.channel = mysql-channel
# sink class, must not be changed
cygnusagent.sinks.mysql-sink.type = es.tid.fiware.fiwareconnectors.cygnus.sinks.OrionMySQLSink
# the FQDN/IP address where the MySQL server runs
cygnusagent.sinks.mysql-sink.mysql_host = 127.0.0.1
# the port where the MySQL server listes for incomming connections
cygnusagent.sinks.mysql-sink.mysql_port = 3306
# a valid user in the MySQL server
cygnusagent.sinks.mysql-sink.mysql_username = ***
# password for the user above
cygnusagent.sinks.mysql-sink.mysql_password = ***
# how the attributes are stored, either per row either per column (row, column)
cygnusagent.sinks.mysql-sink.attr_persistence = column
#=============================================
# hdfs-channel configuration
# channel type (must not be changed)
cygnusagent.channels.hdfs-channel.type = memory
# capacity of the channel
cygnusagent.channels.hdfs-channel.capacity = 1000
# amount of bytes that can be sent per transaction
cygnusagent.channels.hdfs-channel.transactionCapacity = 100
#=============================================
# mysql-channel configuration
# channel type (must not be changed)
cygnusagent.channels.mysql-channel.type = memory
# capacity of the channel
cygnusagent.channels.mysql-channel.capacity = 1000
# amount of bytes that can be sent per transaction
cygnusagent.channels.mysql-channel.transactionCapacity = 100
Any hints?
Thanks
I believe its because you are using parameter column in your configuration for OrionMySQLSink
# how the attributes are stored, either per row either per column (row, column)
cygnusagent.sinks.mysql-sink.attr_persistence = column
In documentation is stated that when using column database and tables must be created before starting of cygnus. When you using row all 8 rows will be created automatically before first insert.
Within tables, we can find two options:
Fixed 8-field rows, as usual: recvTimeTs, recvTime, entityId, entityType, attrName, attrType, attrValue and attrMd. These tables
(and the databases) are created at execution time if the table doesn't
exist previously to the row insertion. Regarding attrValue, in its
simplest form, this value is just a string, but since Orion 0.11.0 it
can be Json object or Json array. Regarding attrMd, it contains a
string serialization of the metadata array for the attribute in Json
(if the attribute hasn't metadata, an empty array [] is inserted),
Two columns per each entity's attribute (one for the value and other for the metadata), plus an addition column about the reception
time of the data (recv_time). This kind of tables (and the databases)
must be provisioned previously to the execution of Cygnus, because
each entity may have a different number of attributes, and the
notifications must ensure a value per each attribute is notified.
The behaviour of the connector regarding the internal representation
of the data is governed through a configuration parameter,
attr_persistence, whose values can be row or column.
As Petark suggest, the "column mode" does not automatically creates the tables, and this must be provisioned in advanced by you. Why? The reason is, depending on the subscription you made to Orion CB in order to sent notifications to Cygnus, such notification may include some times a few attrbute updates, some times other very different attributes set, etc.
For instance, let's consider an entity called "car" with attrbutes "speed", "location" and "oil-level". Then you may say "notify Cygnus each time the speed changes, but send only the speed value. But at the same time you may say "notify Cygnus each time the oil level changes, and send all the attribute's value" as well. If the car starts moving, and only the speed and the location change, but not the oil level, then only the speed updates will be notified to Cygnus, which has no chance to know about the other attributes at any time.
Thus, if you want rows of data having all the 3 attributes, then you have to provision the table by yourself. By the way, having such subscription examples will lead to a lot of "speed-value,null,null" rows in your tables.
The differece with the "row mode" is that, independently of the number of notifed attributes, a new row will be added for each notified attribute, having all the rows the same format (entityId,entitytType,attrName,attrType,attrValue,attrMd); these format can be automatically provisioned by Cygnus.
when i am executing some querys for report purpose ,sometimes those queries are taking 10 mins and some times same queries are taking hours of time and some times we are getting error like communication link failure.when i go through error log i found below error message ,how to fix it.
Error Message:
lock: 0x2b84f402e800:
lock: 0x2b84f401bb80:
lock: 0x2b84f401c410:
lock: 0x2b84f41d45f0:
lock: 0x2b84f41c1990:
lock: 0x22d657d0:
lock: 0x2308c650:
lock: 0x2b84f800d2c0:
lock: 0x22db4040:
lock: 0x22c0fa60:
lock: 0x22bc85a0:
lock: 0x22cf7710:
Key caches:
default
Buffer_size: 402653184
Block_size: 1024
Division_limit: 100
Age_limit: 300
blocks used: 19
not flushed: 0
w_requests: 1
writes: 1
r_requests: 160
reads: 19
handler status:
read_key: 8256766
read_next: 143651263
read_rnd 16764
read_first: 76853
write: 1941561
delete 306347
update: 1781864
Table status:
Opened tables: 149
Open tables: 142
Open files: 55
Open streams: 0
Alarm status:
Active alarms: 0
Max used alarms: 1
Next alarm time: 0
Memory status:
Non-mmapped space allocated from system: 368238592
Number of free chunks: 168
Number of fastbin blocks: 0
Number of mmapped regions: 31
Space in mmapped regions: 761421824
Maximum total allocated space: 0
Space available in freed fastbin blocks: 0
Total allocated space: 357157904
Total free space: 11080688
Top-most, releasable space: 5359328
Estimated memory (with thread stack): 1132281856
Events status:
LLA = Last Locked At LUA = Last Unlocked At
WOC = Waiting On Condition DL = Data Locked
Event scheduler status:
State : INITIALIZED
Thread id : 0
LLA : n/a:0
LUA : n/a:0
WOC : NO
Workers : 0
Executed : 0
Data locked: NO
Event queue status:
Element count : 0
Data locked : NO
Attempting lock : NO
LLA : init_queue:139
LUA : init_queue:149
WOC : NO
Next activation : never
140328 17:17:08 [Warning] IP address 'xxxx' could not be resolved: Name or service not known
140328 17:20:00 [Warning] IP address 'xxxx' could not be resolved: Name or service not known
140328 17:29:43 [Warning] IP address 'xxxx' could not be resolved: Name or service not known
140331 9:55:47 [Warning] IP address 'xxxx' could not be resolved: Name or service not known
140331 9:56:09 [Warning] IP address 'xxxx' could not be resolved: Name or service not known
140331 11:38:35 [Warning] IP address 'xxxx' could not be resolved: Name or service not known
140331 15:07:04 [Warning] IP address 'xxxx' could not be resolved: Name or service not known
If you are querying for report purposes, you shouldn't be locking any records. Ensure you are using with (nolock) in the query statements.