I have added mod-npc-all-mounts. This has SQL script that I execute to create creature_template with ID 601014.
How do I spawn this NPC to various locations in the game ?
I have tried .npc add 601014 and .npc add temp 601014 on a GM account but I just see the help text for, npc commands which suggests .npc add might not be a valid command
Check https://www.azerothcore.org/wiki/gm-commands
It shows the available commands and the required GM levels.
There is also account set gmlevel to grant an account GM rights. This goes to the worldserver console. It needs to login after the rights were changed.
Related
I am using VS Code for R in a remote Unix environment. My goal is to perform regular interactive job while editing the script on the remote server as what people usually do in RStudio locally.
For the HPC server I use, there're a admin node (i.e. login node) and a compute node (mostly for interactive job).
Usually what I did, is to login in via admin node first (via ssh), and then request certain resourses (e.g. memories, cpu, etc) from the compute node, and then do
ssh $SLURM_JOB_NODELIST
which transfer me from 'admin' to 'compute' node in the terminal.
And lastly, I do "R: Create R terminal". However, I wouldn't be able to check if this R terminal is operated on the compute node or the admin node.
There's a way to go around, by using 'radian' package and set "r.alwaysUseActiveTerminal" as "true". However, via this way, my data viewer wouldn't be attached and I couldn't view my data in the 'workspace'. As this,
enter image description here
The trickiest part is I need to use 'ssh' to switch between 'admin' and 'compute node'. While at the same time the whole left panel of VS Code, including the File Viewer, is still based on the 'admin' node.
Any suggestions and advice are welcome! Thanks a lot!
In the R syntax, use Sys.info() to find the hostname of the computer R is running on:
> Sys.info()["nodename"]
nodename
"node002.cluster"
I have created a new mimik developer account, and I was trying get the edge access token using the command "mimik-edge-cli account get-edge-access-token -t <--id token-->". But I am getting an "Error" as response.
I have tried with my previous account and in that case i am able to get the access token as shown below. Same issue happened for raspberrypi too.
why it is not able to get the access token while using a new account?
Please make sure to copy the ID Token from developer portal correctly, In most cases there might be a hidden character copied. Maybe just try copying the text by highlighting with mouse from first character to the last. Do NOT use the copy to clipboard button. Also please make sure that the edgeEngine on the PI is not associated already by checking with:
mimik-edge-cli account get-me
When you input command above, if you see an ID for value "accountId:" then your PI is already associated an CANNOT be associated again. You have to un-associate first and then associate with the new ID token from new account/project. You can verify that un-association is successful when above command shows empty value for "accountId:"
FOR FUTURE REFERENCE:
Please only tag questions with edgeSDK if it is related to FreeRTOS platform. For all other platforms, please use tag edgeEngine
Hello to forum from a part time occasional user of MS Access 2010:
Trying to get permission to allow a third party application read MsysObjects which in turn will allow it to save a copy of the table relationship window in a form that will allow the layout to be recovered when it crashes (frequently - and is a known irritation/bug).
Have tried the method suggested in quote from this forum [HansUp] without success - including substiting this DAO line for the last ADO line following advice on a different forum:
dbEngine(0)(0).Execute strDdl, dbFailOnError
Since your db is ACCDB format, you will be working as user Admin. You can confirm that point in the Immediate window. (Go there with Ctrl+g)
? CurrentUser()
Admin
Since Admin doesn't have read (SELECT) permission on MSysObjects, execute a DDL statement to give Admin that permission.
strDdl = "GRANT SELECT ON MSysObjects TO Admin;"
CurrentProject.Connection.Execute strDdl
Advice from yet another forum to import or export to fresh blank accdb gives no result as permissions are still not available.
All this is beyond my pay grade so any advice welcome.
On a RedHat 6 server, a third party application requires to be root to run and needs access to sqlplus. I have a running database, I can run sqlplus as user 'oracle'. When logged in as user root, 'sqlplus usr/pwd#dbname' works as expected. The trouble is that this agent needs to run sqlplus with no parameters and it always returns ORA-12546: TNS:permission denied.
I've read a dozen times that enabling root to launch Oracle is a security issue but I really have no other choice.
Running Oracle 11.2.0.1.0.
Any help will be much appreciated as I've googled for 2 days with no success.
From the documentation, ORA_12546 is:
ORA-12546: TNS:permission denied
Cause: User has insufficient privileges to perform the requested operation.
Action: Acquire necessary privileges and try again.
Which isn't entirely helpful, but various forum and blog posts (way too many to link to, Googling for the error shows a lot of similar advice) mention permissions on a particular part of the installation, $ORACLE_HOME/bin/oracle, which is a crucial and central part of most of the services.
Normally the permissions on that file would be -rws-r-s--x, with the file owned by oracle:dba, and this error can occur when the word-writable flag - the final x in that pattern - is not set. Anyone in the dba group will still be able to execute it, but those outside will not.
Your listener seems to be fine as you can connect remotely, by specifying #dbname in the connect string. The listener runs as oracle (usually, could be grid with HA, RAC or ASM) so it is in the dba group and can happily hand-off connections to an instance of the oracle executable.
When you connect without going via the listener, you have to be able to execute that file yourself. It appears that root cannot execute it (or possibly some other file, but this is usually the culprit, apparently), which implies the world-writable bit is indeed not set.
As far as I can see you have three options:
set the world-writable bit, with chmod o+x $ORACLE_HOME/bin/oracle; but that opens up the permissions for everyone, and presumably they've been restricted for a reason;
add root to the dba group, via usermod or in the /etc/group; which potentially weakens security as well;
use SQL*Net even when you don't specify #dbname in the connect string, by adding export TWO_TASK=dbname to the root environment.
You said you don't have this problem on another server, and that the file permissions are the same; in which case root might be in the dba group on that box. But I think the third option seems the simplest and safest. There is a fourth option I suppose, to install a separate instant client, but you'd have to set TWO_TASK anyway and go over SQL*Net, and you've already ruled that out.
I won't dwell on whether it's a good idea to run sqlplus (or indeed the application that needs it) as root, but will just mention that you'd could potentially have a script or function called sqlplus that switches to a less privileged account via su to run the real executable, and that might be transparent to the application. Unless you switch to the oracle account though, which is also not a good idea, you'd have the same permission issue and options.
I am getting this error while connecting to IBM MQ. I know that this is because of privileges, but is there any way just to check the connection with IBM MQ?
Please suggest.
The 2035 suggests that your connection is getting to the QMgr. If you had the wrong channel name, host or port you would get back a 2059. The 2035 means that the connection made it to the listener, found a channel of the name that was requested and attempted a connection.
If you want to test past this point it will be necessary to either authorize the ID that you are using to connect or to put an authorized ID in the MCAUSER attribute of the channel.
For a detailed explanation of how the WMQ security works on client channels, see the WMQ Base Hardening presentation at http://t-rob.net/links.
If you enable authorization messages then the 2035 will show up in the event queue. Then you can look at the message and see what ID was used to connect and what options were used too. The 2035 might be because you asked for set authority on the queue manager or something else you aren't supposed to have. The authorization messages wil show you that.
You can also resolve this By setting mcauser('mqm') .. i was able to overcome 2035 error.
Define channel (channel1) chltype (svrconn) trptype (tcp) mcauser(‘mqm’)
Esp thanx to my SENIOR Bilal Ahmad (PSE)
You have to check the privileges with an MQ administrator.
You can use dspmqaut to check the grant.
Below is the sample to give user poc access to Queue Manager QM1 and Queue LQ1
# check the access right of user POC to QM1
dspmqaut -m QM1 -n LQ1 -t q -p poc
# if you want to give access, you should use
setmqaut -m QM1 -n LQ1 -t q -p poc <access Types>
# eg (put everything - in the real live scenario, choose only what you want to grant) :
setmqaut -m QM1 -n LQ1 -t q -p poc +put +get +browse +inq +set +crt +dlt +chg +dsp +passid +setid +setall +clr
Then dont forget to restart QM1 with
endmqm -i QM1
strmqm QM1
Finally, you should be able to proceed without error 2035.
I have been struggling with this for ages too. Eventually I found this solution. (If you can call turning off authentication a solution.)
I am using version
- IBM Websphere 9.1.0.201807091223
From IBM's website they advise turning connection authentication off!!!
Resolving the problem Disable channel authentication
You will need to disable connection authentication, at least
temporarily. There are known issues in FTM for Check with regard to
using MQ connection authorization. These problems are actively being
addressed and fixes will appear in a future fix pack. The target is
fixpack 3.0.0.8.
Steps to disable connection authentication: Open MQ command console
and type runmqsc ALTER
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS)
CHCKCLNT(NONE) CHCKLOCL(NONE) Restart the queue manager for this
change to take effect.
Source http://www-01.ibm.com/support/docview.wss?uid=swg21962081
On this topic if you are using MQSeries 9.1 in a test or development environment you can disable channel authentication with the following approach :
. Launch MQ command line utility with the following :
runmqsc (for example runmqsc QM1)
. Disable authentication for all channels with the following command
ALTER QMGR CHLAUTH (DISABLED)
For a Q/Q-manager running on Windows, you may have to create the user on the Q/Q-manager machine [i.e. create a user on the Q-machine to match the user on the Q-client machine], and then add that user to the 'mqm' group on that machine.
Steps:
Ensure that the domain user that is being used to create the Q CLIENT [i.e. the user that the Q-client app is running under] also exists on the box with the Q/Q-manager. You may be able to just create a local user on the Q/Q-manager box [, or you may have to do some more complicated creation of an Active Directory user - I can't help you there].
On the Q/Q-manager box, add the user you have just created [or the existing one, if it already exists] to the mqm group. [On a Windows server box you will need to use the Microsoft Management Console (1. 'mmc' from the command line, 2. File > Add/Remove SnapOn > Local Users & Groups, 3. add user to group)]. The 'mqm' group should already exist on the Q/Q-manager machine.
Error MQRC 2035 basically means that your application has been able to connect to the queue manager, however due to certain absence of permissions/authorizations, it was unable to put/get/publish/subscribe messages.
To resolve this, at first, try these steps in order to disable the authorizations from queue manager and channel. Use this only if it isn't a production queue manager.
Always check the queue manager logs. It tells you exactly where you need to look into, and resolve the issue.
In this case, generally, you can issue the following commands after doing a runmqsc on the queue manager :
ALTER QMGR CHLAUTH(DISABLED)
Then set the chckclnt object(under authinfo) to optional
DISPLAY QMGR CONNAUTH
DISPLAY AUTHINFO(name-from-above) ALL //name from the first commands
ALTER AUTHINFO(name-from-above) AUTHTYPE(IDPWOS) ADOPTCTX(YES)
ALTER AUTHINFO(name-from-above) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
SET CHLAUTH('*') TYPE(BLOCKUSER) ACTION(REMOVEALL)
This helps remove any blocks that the channel is creating against any user.
SET CHLAUTH(your channel name) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL)
This should resolve your issue, since we have disabled every authorization that an application has to pass in order to do anything on a queue manager.
Now, in case you are using a production queue manager, NEVER remove authorizations.
Go, and right click on any QM that you have configured in your MQ explorer. Go to the QM authority, and authority records. Click on create new user, and give the same name as the username your application is using. Select all the checkboxes, then copy from the space below all the commands that are given. Namely, setmqaut. Edit with your queue manager name, and issue them!
----Never give up, the answer is where you have not looked yet--------