I'm trying to get the authentication mode (WPA/WEP) on all the available AccessPoints via DBUS API(in Linux). NetworkManager API describes a property WPAFLAGS but I don't get anything out of it (I get Null Flag everytime). D-Feet DBUS debugger also doesn't show anything. Am I missing something, or is the API broken?
Looks like you are doing something wrong:
$ dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/AccessPoint/995 org.freedesktop.DBus.Properties.Get string:'org.freedesktop.NetworkManager.AccessPoint' string:'WpaFlags'
method return sender=:1.1188 -> dest=:1.2189 reply_serial=2
variant uint32 324
$ dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/AccessPoint/994 org.freedesktop.DBus.Properties.Get string:'org.freedesktop.NetworkManager.AccessPoint' string:'WpaFlags'
method return sender=:1.1188 -> dest=:1.2190 reply_serial=2
variant uint32 332
$ dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/AccessPoint/991 org.freedesktop.DBus.Properties.Get string:'org.freedesktop.NetworkManager.AccessPoint' string:'WpaFlags'
method return sender=:1.1188 -> dest=:1.2191 reply_serial=2
variant uint32 276
What you posted returns:
dbus-send: Data item "method" is badly formed
I believe question was about:
interface.Get("org.freedesktop.NetworkManager.AccessPoint", "WpaFlags")
and it always returns 0
Related
I run ASR experiment using Kaldi on SGE cluster consisting of two workstation with TITAN XP.
And randomly I meet the following problem:
ERROR (nnet3-train[5.2.62~4-a2342]:FinalizeActiveGpu():cu-device.cc:217) cudaError_t 1 : "__global__ function call is not configured" returned from 'cublasCreate(&handle_)'
I guess something is wrong with GPU driver or hardware.
Could you please offer some help?
And here is the complete log
I had similar issue in running darknet in one of the TX2
with reference to
https://blog.csdn.net/JIEJINQUANIL/article/details/103091537
enter the root by
sudo su
Then source the catkin_ws
Then launch the darkent.
Then can run.
Here is my result
Hope you can solve it by similar method
I am working on Mosquitto and plan to use Redis as the back end to handle both username/password pair authentication and ACL. I am using JPmens' authentication plugin to do this. The authentication works well, but I can't make the ACL work. Redis uses unique keys and the usernames (keys in my cases) are used in username/password pairs for authentication purposes. I have tried to mix user name,password and topics together in sets/list, but none of them work.
the mosquitto conf:
auth_plugin /etc/mosquitto/auth-plug.so
auth_opt_backends redis
auth_opt_redis_host 127.0.0.1
auth_opt_redis_port 6379
auth_opt_redis_userquery GET %s
auth_opt_redis_aclquery GET %s-%s
Following name/password pairs are working fine for the authentication
SET user1 PBKDF2$sha256$901$Qh18ysY4wstXoHhk$g8d2aDzbz3rYztvJiO3dsV698jzECxSg
SET user2 PBKDF2$sha256$901$R74X2ae3MufMS20M$CAbXZFDmXJN7Cc28Dm/Z97OfM8Tz1JHn
...
Following settings won't work for the ACL: (a/b... as topics)
sadd user22 PBKDF2$sha256$901$Qh18ysY4wstXoHhk$g8d2aDzbz3rYztvJiO3dsV698jzECxSg a/b c/d
rpush user33 PBKDF2$sha256$901$q5/N74O6Iaf/e8Cg$dEA3tZSi/sJeXKAkX39Gd3agy2WY96gE e/f
What's the correct way to do so?
In the Redis API, aclrequery shows that:
Single stepping until exit from function be_redis_aclcheck, which has no line number information.
redisCommand (c=0x6537d0, format=0x6561c0 "GET user1-t/c") at hiredis.c:1345
1345 void *redisCommand(redisContext *c, const char *format, ...) {
(gdb) bt
0 redisCommand (c=0x6537d0, format=0x6561c0 "GET my-t/c") at hiredis.c:1345
1 0x00007ffff5e61376 in be_redis_aclcheck () from /etc/mosquitto/auth-plug.so
2 0x00007ffff5e5c351 in mosquitto_auth_acl_check ()
from /etc/mosquitto/auth-plug.so
Here, user1 is the user name and t/c is the topic. GET user1-t/c seems to tell me a string type is expected in the Redis database. Can anyone give me an example of how to get this to work?
Thanks
I have figured out how it works. If MQTT broker only allow client user1 to pub and sub "a/b" and "c/d" topics, the correct ACL data in Redis for the JPmens plugin will be:
user1-a/b 2
user1-c/d 2
"user1-a/c" is the key and 2 is the value.
It's not preferred, if Redis goes down for any reason your entire system will be down also.
It will be a SPF (single point of failure) in your architecture.
Tried with a similar question earlier, but could not I make headway. So I did new tests and here is the new question:
I did a brand new installation of PHARO 1.4 and GEMSTONE 3.0.1.2 on the same machine. (Linux CENTOS). Loaded seaside 3.0 in Pharo and version 3.0.7.1 in Gemstone using the latest version of Gemtools (1.0 beta 87) with the latest version of glass workspace (1.0 beta 8.7.4).
I opened the workspace and evaluated:
(WAEmailMessage
from: (WAEmailAddress address: 'xx#aa.com' username: 'fromMe')
to: (WAEmailAddress address: 'shyam#localhost' username: 'shyam')
subject: 'Email Test')
body: 'This is a Test Email sent';
send.
(BTW, As the default mail host in Gemstone is "mailhost", I added the following line to the /etc/hosts file127.0.0.1 localhost mailhost ).
On Pharo the message is sent and received correctly, while in Gemstone I get
a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand #'isEmpty', in the method
readSmtpResult
| result firstChar |
[self readWillNotBlockWithin: 5000]
whileFalse: [GsFile stderr log: 'Waiting for server to write...'].
result := self readString: 500.
result isEmpty =========================> HERE result is "nil".
ifTrue:
[self log: 'Empty result'.
^false].
The reason being that result returns a nil.
I tried with similar results also on MAC OS X which instead went into a loop in the lines above.
Using tcpdump -X -i lo tcp port 25 and WireShark, I noticed that for GEMSTONE, I saw NO activity while the packets were correctly exchanged for PHARO.
Evidently, I am doing something terribly wrong to get it wrong on two different systems.
Any idea ?
Thanks
Shyam.
result is nil because #readString: returned nil.
It seems that the peer does not send any data. As you already traced that there is no activity on port 25 going on, are you sure that the SMTP parameters are correct?
Seaside-Email contains code that you can use to configure your SMTP-Server.
Given you have your Seaside application seasideApp, you can do the following:
seasideApp configuration
addParent: WAEmailConfiguration instance.
seasideApp
preferenceAt: #smtpServer put: 'your.smtp.host';
preferenceAt: #smtpPort put: 25;
preferenceAt: #smtpUsername put: 'your.smtp.username.or.nil.if.unecessary';
preferenceAt: #smtpUsername put: 'your.smtp.password.or.nil.if.unecessary';
yourself.
Note that #smtpServer and smtpPort must be configured the way described, as they are used in the GemStone version of GRPlatform>>#seasideDeliverEmailMessage:. I opted to deliberately not use the GemStone defaults.
Also, setting the SMTP parameters this way is ment to work cross-platform; if it does not, please contact me directly.
I'm trying to debug some Redis issues I am experiencing and came by some inconclusive documentation about the SET command.
In my Redis config; I have the following lines (snippet):
# Note: with all the kind of policies, Redis will return an error on write
# operations, when there are not suitable keys for eviction.
#
# At the date of writing this commands are: set setnx setex append
On the documentation page for the SET command I found:
Status code reply: always OK since SET can't fail.
Any insights on the definitive behaviour?
tl;dr: SET will return an error response if the redis instance runs out of memory.
As far as I can tell from the source code in redis.c, esentially when a command is to be processed the flow goes like this (pseudo code):
IF memory is needed
IF we can free keys
Free keys
Process the command
SET -> process and return OK response
ELSE return error response
ELSE
Process command
SET -> process and return OK response
It's not exactly written this way, but the basic idea comes down to that: memory is being checked before the command is processed, so even if the command cannot fail, an error response will be returned if there's no memory regardless the actual response of the command.
I'm attempting to execute an uninstaller (written in AppleScript) through AuthorizationExecuteWithPrivileges. I'm setting up my rights after creating an empty auth ref like so:
char *tool = "/usr/bin/osascript";
AuthorizationItem items = {kAuthorizationRightExecute, strlen(tool), tool, 0};
AuthorizationRights rights = {sizeof(items)/sizeof(AuthorizationItem), &items};
AuthorizationFlags flags = kAuthorizationFlagDefaults |
kAuthorizationFlagExtendRights |
kAuthorizationFlagPreAuthorize |
kAuthorizationFlagInteractionAllowed;
status = AuthorizationCopyRights(authorizationRef, &rights, NULL, flags, NULL);
Later I call:
status = AuthorizationExecuteWithPrivileges(authorizationRef, tool, kAuthorizationFlagDefaults, (char *const *)args, NULL);
On Snow Leopard this works fine, but on Leopard I get the following in syslog.log:
Apr 19 15:30:09 hostname /usr/bin/osascript[39226]: OpenScripting.framework - 'gdut' event blocked in process with mixed credentials (issetugid=0 uid=501 euid=0 gid=20 egid=20)
Apr 19 15:30:12: --- last message repeated 1 time ---
...
Apr 19 15:30:12 hostname [0x0-0x2e92e9].com.example.uninstaller[39219]: /var/folders/vm/vmkIi0nYG8mHMrllaXaTgk+++TI/-Tmp-/TestApp_tmpfiles/Uninstall.scpt:
Apr 19 15:30:12 hostname [0x0-0x2e92e9].com.example.uninstaller[39219]: execution error: «constant afdmasup» doesn’t understand the «event earsffdr» message. (-1708)
After researching this for a few hours my first guess is that Leopard somehow doesn't want to do what I'm doing because it knows it's in a setuid situation and blocks calls that ask about user-specific things in the applescript.
Am I going about this all wrong? I just want to run the equivalent of "sudo /usr/bin/osascript ..."
Edit:
FWIW, the first line that causes the "execution error" is:
set userAppSupportPath to (POSIX path of (path to application support folder from user domain))
However, even with an empty script (on run argv, end run and that's it) I still get the 'gdut' message.
According to this thread. http://forums.macosxhints.com/showthread.php?t=90952&page=3 It appears that a security update was made to OS X that blocks setuid root scripts from being accessed via AppleScript.
I suspect this mechanism is blocking your code as well.
Unfortunately, I guess that means this is not working "by design".