wicked Development

wicked-devel@lists.opensuse.org

31 discussions

[wicked-devel] Wicked and dbus Support questions

by koorapati, koundinya

Hi Wicked Developers, We are working on a new feature in our product with SELS15 OS, where we want to programmatically leverage Wicked and dbus integration. We have process A for which we want to get it notified of any change in the state of the ethernet interfaces such as linkdown, linkup, MTU change etc. We came across the gdbus API where there seemed to be a solution for what we want. We have written some sample programs using gdbus API. Here are few code snippets: static void on_signal (GDBusProxy *proxy, char *sender_name, char *signal_name, GVariant *parameters, gpointer user_data) { guint32 new_state; /* Print all signals */ char *parameters_str; parameters_str = g_variant_print (parameters, TRUE); g_print (" *** Received Signal: %s: %s\n", signal_name, parameters_str); g_free (parameters_str); printf("in on_signal \n"); g_print ("Interface Name %s \n", g_dbus_proxy_get_interface_name(proxy)); g_print ("Object Path %s \n", g_dbus_proxy_get_object_path (proxy)); /* We are only interested in "StateChanged" signal */ if (strcmp (signal_name, "StateChanged") == 0) { GVariant *tmp = g_variant_get_child_value (parameters, 0); new_state = g_variant_get_uint32 (tmp); g_variant_unref (tmp); g_print ("NetworkManager state is: (%d) %s\n", new_state, nm_state_to_string ((NMState) new_state)); } } main() { . . proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SYSTEM, flags, NULL, /* GDBusInterfaceInfo */ "org.opensuse.Network", "/org/opensuse/Network", "org.opensuse.Network", NULL, /* GCancellable */ &error); /* Connect to g-signal to receive signals from proxy (remote object) */ g_signal_connect (proxy, "g-signal", G_CALLBACK (on_signal), NULL); /* Run main loop */ loop = g_main_loop_new (NULL, FALSE); g_main_loop_run (loop); g_object_unref (proxy); return 0; } Now, when the interfaces are brought down using wicked ifdown/ifup commands, the program is able to catch the signals. Additionally, we also want to have the ability to bring down the interfaces in the program. So we tried something like using g_dbus_proxy_new_for_bus_sync() main() { GError *error = NULL; GDBusProxyFlags flags; GDBusProxy *proxy; g_print ("Running Proxy Command \n"); g_print ("==============================\n"); flags = G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES | G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START; proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SYSTEM, flags, NULL, /* GDBusInterfaceInfo */ "org.opensuse.Network", "/org/opensuse/Network/Interface/4", "org.opensuse.Network.Interface", NULL, /* GCancellable */ &error); if (proxy == NULL) { g_dbus_error_strip_remote_error (error); g_printerr ("Error creating D-Bus proxy: %s\n", error->message); g_error_free (error); return -1; } g_dbus_proxy_call_sync (proxy, "linkUp", NULL, G_DBUS_CALL_FLAGS_NONE, -1, NULL, &error); g_object_unref (proxy); return 0; } Does Suse recommend using the gdbus APIs to programmatically achieve dbus and wicked communication for third party programs/applications? We need this info as we need to freeze on the architecture and design for our new feature. If Suse does not recommend gdbus APIs, please let us know if there are robust alternatives to what we are trying to achieve. How do we know the APIs that are exposed by Wicked for dbus? Thank You, Koundinya -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

2 years, 1 month

[wicked-devel] Looking to contribute

by ruben.torrero＠gmail.com

Hi everyone, I'm taking a few 12-hour flights starting next week and until march. I was checking out some project I'd like to contribute to try and make good use of that time and I was wondering if you might have any notes on how to start and what issues to take. I've been taking a look at the list of issues on your GitHub repo but most issues seem quite old, should I pick any of those or look somewhere else? Thanks, Rubén Torrero Marijnissen -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

4 years, 3 months

[wicked-devel] Re: Wicked permissions

by Saulo A. Moraes

Hi, Is it possible to individual users create their own wifi connections? Seems that users dont have permission to set their our network connection... Thx, Saulo -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

4 years, 6 months

[wicked-devel] DHCLIENT6_MODE=managed no longer working

by Scott Simpson

I set the DHCLIENT6_MODE variable to "managed" last year like this: https://lists.opensuse.org/wicked-devel/2016-02/msg00000.html This worked until recently. I got the IPv6 global IP. It stopped working recently and I'm wondering if something changed in the kernel or via dhclient? Scott Simpson -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

4 years, 9 months

[wicked-devel] wlan re-connect happens not automatic?

by Adrian Schröter

Hi, I have kind of a private problem with Raspberry PI3 server running openSUSE 42.2. It it is connected via wireless and seems to work stable. However it seems not to re-connect when the wlan route got power cycled for some reason. I am unfortunately unable to debug the state, given that the box is some hundred kilometers away. But a power cycle is bringing it back. However, is wicked supposed to re-connect in such a situation? Is there some configuration or debug option which I should check to have some log informations when it happens the next time? thanks adrian -- Adrian Schroeter email: adrian(a)suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

5 years, 2 months

[wicked-devel] Question about bringing up devices in a bond

by Jason Schultz

I have an application that’s responsible for configuring the network on the host; it writes configuration files to /etc/sysconfig/network, and then invokes ifup, ifdown, etc to up and down interfaces and bonds. Since moving to SLES 12 SP1 and wicked and the wicked nanny daemon, we are seeing an issue I’m hoping someone on this list may be able to help with. This issue does not occur on SLES 11 systems using Network Manager. The scenario is as follows. To bring up a bond, the application does the following. (The NIC names and file names I’m using are just for the purpose of the example): Create a config file for p5p2 and copy/write the file to /etc/sysconfig/network/ifcfg-p5p2 ifup p5p2 Create a config file for p5p2 and copy/write the file to /etc/sysconfig/network/ifcfg-p5p4 ifup p5p4 Creates a config file for the bond and copy/write the file to /etc/sysconfig/network/ifcfg-bond0cpc1 ifup bond0cpc1 Everything works fine the first time, after a fresh Linux boot. I then manually bring down the NICs/bonds with ifdowns and remove the files from the /etc/sysconfig/network directory. Then, the second time I attempt to perform the same steps to bring up the same NICs and bond, I see the following: Create a config file for p5p2 and copy the file to /etc/sysconfig/network/ifcfg-p5p2 ifup p5p2 (works fine) Create a config file for p5p2 and copy the file to /etc/sysconfig/network/ifcfg-p5p4 ifup p5p4 (works fine) Create a config file for the bond and copy the file to /etc/sysconfig/network/ifcfg-bond0cpc1 ifup bond0cpc1 (*** fails) On the failure of the ifup of the bond the second time, the ifup returns “device-not-running”, and the same failure is exhibited over and over again. So the main question is, why is that? The NIC I’m using is the Intel Corporation I350 Gigabit Network Connection (4-port, copper). Here’s some more info. If I execute the ifups in a shell script so that there’s very little time delay between copying the files into the /etc/sysconfig/network directory and ifup’ing the devices, it works every time. cp ifcfg-p5p2 ifcfg-p5p4 /etc/sysconfig/network ifup p5p2 ifup p5p4 cp ifcfg-bond0cpc0 /etc/sysconfig/network ifup bond0cpc0 If you now ifdown the devices and remove their ifcfg- files from /etc/sysconfig/network and re-run the script, it works every time. Doing the commands from the command line, or putting delays in the shell script; that is, putting sleeps between copying the files to the /etc/sysconfig/network directory and ifup’ing the devices, fails every time. I tried manual configuration of a bond on the Intel Corporation I350 Gigabit Fiber Network Connection (4-port, fiber) and it works every time regardless. Finally, if I disable the nanny daemon by editing /etc/wicked/common.xml (setting <use-nanny>false</use-nanny> and restarting the wicked service) manual ifup’ing works regardless. Does anyone have any ideas on what the issue could be? Thanks in advance. -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

5 years, 3 months

Re: [wicked-devel] any way of keeping a fixed duid.xml ?

by Per Jessen

> Hi! > > Yes, you can pass it to linuxrc (installer/rescue) via kernel > parameter like this: > >ifcfg=*=dhcp,DHCLIENT6_CLIENT_ID=00:01:00:01:1f:b8:72:38:00:19:99:4e:1e:98 > ^ > | > interface name > > or also the shorter type 3 DUID (non-persistent store duid-ll, > without 1f:b8:72:38 time in secs since 2001 % 2^32): > > ifcfg=*=dhcp,DHCLIENT6_CLIENT_ID=00:03:00:01:00:19:99:4e:1e:98 > ^^^^^ ^^^^^ ^^^^^^^^^^^^^^^^^ > duid hwaddr hw (mac) address > type type Ok, that's great, thanks. > BTW: The "hardware ethernet 00:19:99:4e:1e:98" in ISC dhcpd6 is > matching the mac in both duid types, regardless of the time... You're sure? I can't make that work - I have this definition host office13 { ddns-hostname "office13"; option host-name "office13"; hardware ethernet 00:01:6c:84:9a:80; host-identifier option dhcp6.client-id 00:01:00:01:1b:fd:ee:d9:00:01:6c:84:9a:80; } Only when I keep "host-identifier option dhcp6.client-id" is the host recognised. I'm running isc dhcp 4.3.3. Sorry about the late reply, I thought I was subscribed to wicked-devel, but I wasn't. -- Per Jessen, Zürich (3.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

5 years, 7 months

[wicked-devel] any way of keeping a fixed duid.xml ?

by Per Jessen

I already asked on opensuse-general, but no answers - As far as I can tell, duid.xml (/var/lib/wicked/duid.xml) is generated during installation, but at least partially based on an interface MAC address: 00:01:00:01:1f:b8:72:38:00:19:99:4e:1e:98 When testing and re-installing or booting a rescue system somewhat frequently, it is most annoying to have the duid change all the time. I have to either amend dhcp6.conf or edit the duid directly once the system is installed. Is there a way (kernel argument perhaps?) to stop the duid changing? Thanks Per Jessen -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

5 years, 7 months

[wicked-devel] OVS interface bringup in wickedd

by Bolesław Tokarski

Hello, I know OVS support in wickedd is limited, and I might have some setup that is more than supported, but I hope we can get somewhere with this. I am still running the 42.1 wicked version 0.6.31. I have two OVS bridges, I'll skip the 'tunnels' bridge, as I don't configure any interfaces on it through wickedd. It's just for reference, if wicked behaves differently if it has more than one bridge. Then, I have the 'vms' OVS bridge that I use for KVM - I specify the VLANs the VMs are to join. The VMs connect fine, so also out of scope. I configure the 'vms' bridge: ovs-vsctl add-br vms On the host side, I only want connect to one of these VLANs - vlan100, so I configure only that: # cat /etc/sysconfig/network/ifcfg-vlan100 MTU='1394' STARTMODE='auto' BOOTPROTO='static' OVS_BRIDGE='yes' OVS_BRIDGE_VLAN_PARENT='vms' OVS_BRIDGE_VLAN_TAG='100' BROADCAST='10.100.0.255' IPADDR='10.100.0.4' NETMASK='255.255.255.0' NETWORK='10.100.0.0' Then, I run an ifup vlan100 and everything seems fine... but. After reboot I get (I am skipping most logs for now, there's nothing interesting in them but this): vlan100: <parent> element references unknown device vms vlan100: cannot resolve reference ovs-bridge/vlan/parent to subordinate device yet ... and it seems the vms bridge disappeared! The 'tunnels' bridge is there after a reboot, they are persistently stored in OVS's DB, so it must have been removed by... wicked! Unfortunately, although I set journald.conf's Storage=persistent, I wasn't able to get logs from before a reboot. I don't see why wicked would remove any bridges, but well... that reproduces on every reboot. I found some code that removes OVS bridges in the wicked code... Why is that there? And even so, I did not tell wicked to configure 'vms' interface nor bridge, just a vlan100 port inside it, so it being removed is somewhat unexpected. Another pecularity: After the boot I re-create the vms bridge, ifup vlan100. Then I remove the bridge and re-create it yet again, without doing an ifdown vlan100 first. Then: # ifup vlan100 vlan100 no-device # ifdown vlan100 wicked: ifdown: no matching interfaces Subsequent bringup of the interface works: # ifup vlan100 vlan100 up Best regards, Bolesław Tokarski -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

5 years, 9 months

Re: [wicked-devel] Wicked totally fails for eth card if the link is physically down at startup

by Jason Schultz

I hope I am not starting a new thread with this, I am attempting to reply to Nikolai Zhubr's last message from his thread: https://lists.opensuse.org/wicked-devel/2016-03/msg00004.html I had started a similar thread a couple weeks before that here, which also did not get a response: https://lists.opensuse.org/wicked-devel/2016-03/msg00000.html The reason for replying again is to agree with the conclusion that "LINK_REQUIRED=no" should be the default in order to prevent this type of issue when there's no physical link. As I explained in my previous post, I thought there would already be a solution to this issue that would require less manual configuration, such as setting LINK_REQUIRED=no in /etc/sysconfig/network/config but this did not work for me. I spent some time looking at the source code to see if I could find an option in the XML files that would work to change the default behavior, but I was unsuccessful. I'm just asking again if anyone has come up with a better solution. Regards, Jason -- To unsubscribe, e-mail: wicked-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: wicked-devel+owner(a)opensuse.org

6 years

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wicked Development