getProperties method not found for NetworkManager - dbus

I am going through dbus-python tutorial.
https://dbus.freedesktop.org/doc/dbus-python/tutorial.html#interfaces-and-methods
The example provided does not work for me. I replaced the eth0 with 1 but still it throws an error.
import dbus
bus = dbus.SystemBus()
eth0 = bus.get_object('org.freedesktop.NetworkManager',
'/org/freedesktop/NetworkManager/Devices/eth0')
eth0_dev_iface = dbus.Interface(eth0,
dbus_interface='org.freedesktop.NetworkManager.Devices')
props = eth0_dev_iface.getProperties()
Error:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send
message, 2 matched rules; type="method_call", sender=":1.4371" (uid=78105 pid=8231
comm="python3 " label="unconfined") interface="org.freedesktop.NetworkManager.Devices"
member="getProperties" error name="(unset)" requested_reply="0" destination=":1.11"
(uid=0 pid=1122 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Also there is this below statement
For instance, each NetworkManager object representing a network interface implements the interface org.freedesktop.NetworkManager.Devices, which has methods like getProperties.
I checked with d-feet, somehow the interface of network manager does not have getProperties method

'/org/freedesktop/NetworkManager/Devices/eth0' is not a D-Bus path that you'll see on NetworkManager's D-Bus API.
You said, you were checking with d-feet. There you'll see that on NetworkManager's D-Bus API, objects commonly have a number at the end. So D-Bus paths to device "objects" are named like /org/freedesktop/NetworkManager/Devices/1.
Try also busctl tree org.freedesktop.NetworkManager.
I checked with d-feet, somehow the interface of network manager does not have getProperties method
NetworkManager's D-Bus API doesn't literally have a getProperties method. It implements the standard D-Bus API with org.freedesktop.DBus.Properties interface as specified (https://dbus.freedesktop.org/doc/dbus-specification.html). Maybe the python bindings expose that as a getProperties() method...
Try:
$ busctl call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/Devices/1 org.freedesktop.DBus.Properties Get ss org.freedesktop.NetworkManager.Device Path`
and
$ busctl -j call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/Devices/1 org.freedesktop.DBus.Properties GetAll s org.freedesktop.NetworkManager.Device

Related

Flink Stateful functions - How to register statefun's ValueSpec in embedded module

I am refactoring my Flink Statefuns for embedded service deployment, but I cannot find the way to register statefun's ValueSpec in EmbeddedModule
When I was using remote http service deployment on k8s, I was building StatefulFunctionSpec with statefun's all value specs inside, and was registering it by StatefulFunctions.withStatefulFunction(spec):
Build static spec in MyStatefun:
static StatefulFunctionSpec SPEC = StatefulFunctionSpec.builder(MY_TYPE)
.withValueSpecs(MY_VALUE_SPEC)
.withSupplier(MyStatefun::new)
.build();
Register it in StatefulFunctions:
StatefulFunctions functions = new StatefulFunctions();
functions.withStatefulFunction(MyStatefun.SPEC);
And finally use functions.requestReplyHandler() as a handler in http server.
What's the way of doing that in EmbeddedModule?
In examples that I found so far, I only see that statefun is registered as this, but does this also register ValueSpecs?
binder.bindFunctionProvider(MyStatefun.FUNCTION_TYPE, x -> (StatefulFunction) new MyStatefun());
UPD. It seems that .bindFunctionProvider(...) cannot bind sdk.java.StatefulFunction, it can only bind sdk.StatefulFunction, which implements .invoke(sdk.Context, Object o) instead of .apply(sdk.java.Context, Message msg). And sdk.Context does not have .storage() method for accessing ValueSpecs.
UPD2. Found page about PersistedValue that could be used for state management and could possibly be the answer to my question: https://nightlies.apache.org/flink/flink-statefun-docs-master/docs/sdk/flink-datastream/

What is the meaning of 'sender=:1.478' in dbus-monitor?

Nowadays I am analyzing d-bus in Chromium OS (Chrome OS).
I captured meaningful d-bus method calls (below), when I press ''guest' button on login UI.
my-cros # dbus-monitor --system "path=/org/chromium/Session Manager"
method call time=1632311881.319994 sender=: 1.478 -> destination=org.chromium. SessionManager serial=378 path=/org/chromium/Session Manager; interface=org.chromium.SessionManager Interface: member=LoadShil1Profile
string "$guest"
method call time=1632311881.319417 sender:1.478 -> destination=org. chromium. Session Manager serial=371 path=/org/chromium/SessionManager; interface=org.chromium.SessionManager Interface: member-SetFeatureFlagsFor User string "$guest"
array [
]
array [
]
I know that org.chromium.SessionManager is the one who starts guest/google-id session.
Btw what is the meaning of 'sender=:1.478'?
And how to track the sender process?
Thank you in advance.
Firstly, you might find it easier to visualise what’s going on by using Bustle instead of dbus-monitor.
sender=:1.478 means the message you’re looking at was sent by the connection with unique ID :1.478 on the bus. Each connection to the bus (roughly, each process, although a process can actually have more than one connection) has a unique ID, and some connections also have ‘well-known’ IDs which look like reverse-DNS names. For example org.chromium.SessionManager.
You can track the sender process by looking for the same unique ID appearing as the sender or destination of other messages. Using Bustle will make this easier, as it can group and filter messages by sender/destination.

Passing a FD to an unnamed pipe over DBus using Vala

I'm trying to send a large block of data between applications by sending a control message over DBus from one to the other requesting a Unix file descriptor. I have it so that the client can request this, the server creates a DBus message that includes a UnixFDList, and the client receives a reply message but it doesn't contain anything. On the server side in Vala the DBusConnection object is setup using register_object, unfortunately the Vapi hides the DBusInterfaceVTable parameter that all the C examples use that would let me specify a delegate for method calls. I've tried to use register_object_with_closures instead but I can't seem to get that to work and the Closure object in Vala is woefully undocumented.
It seems to me that I need one of these methods in order to receive the message from the DBusMethodInvocation object that you get from a call to the DBusInterfaceMethodCallFunc delegate, with that you can create a reply message. Is there a way to either specify a closure class that works with register_object_with_closures, or a way to specify a DBusInterfaceVTable object as part of the service data?
I know that one option is to just create the service in C, but I'd rather figure out and understand how this works in Vala.
Vala uses UnixFDList internally for methods that contain a parameter of type GLib.UnixInputStream, GLib.UnixOutputStream, GLib.Socket, or GLib.FileDescriptorBased.
Example:
[DBus(name="eu.tiliado.Nuvola")]
public interface MasterDbusIfce: GLib.Object {
public abstract void get_connection(
string app_id,
string dbus_id,
out GLib.Socket? socket,
out string? token) throws GLib.Error;
}

Netty synchronous client with asynchronous callers

I am creating a server which consumes commands from numerous sources such as JMS, SNMP, HTTP etc. These are all asynchronous and are working fine. The server maintains a single connection to a single item of legacy hardware which has a request/reply architecture with a custom TCP protocol.
Ideally I would like a single command like this blocking type method
public Response issueCommandToLegacyHardware(Command command)
or this asynchronous type method
public Future<Response> issueCommandToLegacyHardware(Command command)
I am relatively new to Netty and asynchronous programming, basically learning it as I go along. My current thought is that my LegacyHardwareClient class will have public synchronized issueCommandToLegacyHardware(Command command), will make a write to the client channel to the legacy hardware, then take() from a SynchronousQueue<Response> which will block. The ChannelInboundHandler in the pipeline will offer() a Response to the SynchronousQueue>Response> which will allow the take() to unblock and receive the data.
Is this too convoluted? Are there any examples around of synchronous Netty client implementations that I can look at? Are there any best practices for Netty?
I could obviously use just standard Java sockets however the power of Netty for parsing custom protocols along with the ease of maintaniability is far too great to give up.
UPDATE:
Just regarding the implementation, I used an ArrayBlockingQueue<>() and I used put() and remove() rather than offer() and remove(). Because I wanted to ensure that subsequent requests to the legacy hardware were only sent when any active requests had been replied to as the legacy hardware behaviour is not known with certainty otherwise.
The reason offer() and remove() did not work for me was that the offer() command would not pass anything if there was not an actively blocking take() request no the other side. The converse is true that remove() would not return anything unless there was a blocking put() call inserting data.
I couldn't use a put()/remove() since the remove() statement would never be reached since there was no request written to the channel to trigger the event from where the remove() would be called. I couldn't use offer()/take() since the offer() statement would return false since the take() call hadn't been executed yet.
Using the ArrayBlockingQueue<>() with a capacity of 1, it ensured that only one command could be executed at once. Any other commands would block until there was sufficient room to insert, with a capacity of 1 this meant it had to be empty. The emptying of the queue was done once a response had been received from the legacy hardware. This ensured a nice synchronous behaviour toward the legacy hardware but provided an asynchronous API to the users of the legacy hardware, for which there are many.
Instead of designing your application on a blocking manner using SynchronousQueue<Response>, design it in a nonblocking manner using SynchronousQueue<Promise<Response>>.
Your public Future<Response> issueCommandToLegacyHardware(Command command) should then use offer() to add a DefaultPromise<>() to the Queue, and then the netty pipeline can use remove() to get the response for that request, notice I used remove() instead of take(), since only under exceptional circumstances, there is none element present.
A quick implementation of this might be:
public class MyLastHandler extends SimpleInboundHandler<Response> {
private final SynchronousQueue<Promise<Response>> queue;
public MyLastHandler (SynchronousQueue<Promise<Response>> queue) {
super();
this.queue = queue;
}
// The following is called messageReceived(ChannelHandlerContext, Response) in 5.0.
#Override
public void channelRead0(ChannelHandlerContext ctx, Response msg) {
this.queue.remove().setSuccss(msg); // Or setFailure(Throwable)
}
}
The above handler should be placed last in the chain.
The implementation of public Future<Response> issueCommandToLegacyHardware(Command command) can look:
Channel channel = ....;
SynchronousQueue<Promise<Response>> queue = ....;
public Future<Response> issueCommandToLegacyHardware(Command command) {
return issueCommandToLegacyHardware(command, channel.eventLoop().newPromise());
}
public Future<Response> issueCommandToLegacyHardware(Command command, Promise<Response> promise) {
queue.offer(promise);
channel.write(command);
return promise;
}
Using the approach with the overload on issueCommandToLegacyHardware is also the design pattern used for Channel.write, this makes it really flexable.
This design pattern can be used as follows in client code:
issueCommandToLegacyHardware(
Command.TAKE_OVER_THE_WORLD_WITH_FIRE,
channel.eventLoop().newPromise()
).addListener(
(Future<Response> f) -> {
System.out.println("We have taken over the world: " + f.get());
}
);
The advantage of this design pattern is that no unneeded blocking is used anywhere, just plain async logic.
Appendix I: Javadoc:
Promise Future DefaultPromise

Using Objectify For retrieving from Datastore- Error :Did you forget to inherit required module

I am using Objectify for retrieving data From datastore in GWT,But i get the Following Error :
[ERROR] No source code is available for type
com.logins.entity.experts; did you forget to inherit a required
module?
I have Client->entity->Server and i did define the RPC properly with RemoteServicePath.
i intiaized the Rpc in client side
final findexpertAsync
finexp=(findexpertAsync)GWT.create(findexpert.class);
GWT compiler throws Error at the method i call,
finexp.expert(expnam, new AsyncCallback<ArrayList<experts>>()
Note:
1) findexpert and FindexpertAsync are the RPC interface which has a method for retriving data from datastore
2)com.logins.entity.experts:experts is a server class.
Any guesses where i am going wrong ?
All classes directly or indirectly referenced from the client must be part of the client source path. You can't access server-only code from GWT. In this case, class "experts" needs to be part of the GWT-compiled client code.
Also: You should capitalize Java class names.

Resources