| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Consumers of the sd-bus convenience API can't make convenience
helpers of their own without va_list variants.
This commit is a mechanical change splitting out the existing function
bodies into bare va_list variants having a 'v' suffixed to the names.
The original functions now simply create the va_list before forwarding
the call on to the va_list variant, and the va_list variants dispense
with those steps.
|
| |\
| |
| | |
DHCPv6: Add support to send MUD URL
|
| | | |
|
| | | |
|
| |\ \
| | |
| | | |
DHCP4: Add support to emit and receive SMTP servers.
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Export sd-path functions and beef up systemd-path to show more items
|
| | | | |
| | | |
| | | |
| | | | |
Inspired by https://lists.freedesktop.org/archives/systemd-devel/2020-March/044169.html.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
So far we had various ad hoc APIs to query search paths:
systemd-analyze unit-paths, lookup_paths_log(), the pkgconfig file,
debug logs emitted by systemd-analyze cat-config.
But answering a simple question "what is the search path for tmpfiles,
sysusers, .network files, ..." is surprisingly hard.
I think we should have an api that makes it easy to query this. Pkgconfig is
not bad, but it is primarily a development tool, so it's not available in many
context. Also it can't provide support for paths which are influenced by
environment variables, and I'd like to be able to answer the question "what is
the search path for ..., assuming that VAR_FOO=... is set?".
Extending sd-path to support more of our internal paths seems to be most
flexible solution. We already have systemd-path which provides a nice
way to query, and we can add stuff like optional descriptions later on.
We we essentially get a nice programmatic and commmandline apis for the price
of one.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Those are not terribly imporant functions, but we have them, and there's
no reason not to export them.
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I think the two names were both pretty bad. They did not give a proper hint
what the difference between the two functions is, and sd_path_home sounds like
it is somehow related to /home or home directories or whatever, when in fact
both functions return the same set of paths as either a colon-delimited string
or a strv. "_strv" suffix is used by various functions in sd-bus, so let's
reuse that.
Those functions are not public yet, so let's rename.
|
| | |/
|/| |
|
| | | |
|
| |/ |
|
| | |
|
| |\
| |
| | |
Add two man pages for sd-bus
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
codesearch.debian.net shows no uses (except for the definition in systemd and
elogind).
$ cat > test.c
int main() {
sd_bus_try_close(NULL);
return 0;
}
$ gcc -Isrc/systemd -Wall -o testbus test.c -lsystemd
test.c: In function ‘main’:
test.c:4:3: warning: ‘sd_bus_try_close’ is deprecated [-Wdeprecated-declarations]
4 | sd_bus_try_close(NULL);
| ^~~~~~~~~~~~~~~~
In file included from test.c:1:
src/systemd/sd-bus.h:180:5: note: declared here
180 | int sd_bus_try_close(sd_bus *bus) _sd_deprecated_; /* deprecated */
| ^~~~~~~~~~~~~~~~
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When specifying `DHCPv4.SendOption=`, it is used by systemd-networkd to
set the value of that option within the DHCP request that is sent out.
This differs to setting `DHCPServer.SendOption=`, which will place all
the options together as suboptions into the vendor-specific information
(code 43) option.
This commit adds two new config options, `DHCPv4.SendVendorOption=` and
`DHCPServer.SendVendorOption=`. These both have the behaviour of the old
`DHCPServer.SendOption=` flag, and set the value of the suboption in the
vendor-specific information option.
The behaviour of `DHCPServer.SendOption=` is then changed to reflect
that of `DHCPv4.SendOption=`. It will set the value of the corresponding
option in the DHCP request.
|
| |\
| |
| | |
network: tc-next
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
When authorizing via PolicyKit we want to process incoming method calls
twice: once to process and figure out that we need PK authentication,
and a second time after we aquired PK authentication to actually execute
the operation. With this new call sd_bus_enqueue_for_read() we have a
way to put an incoming message back into the read queue for this
purpose.
This might have other uses too, for example debugging.
|
| |\
| |
| | |
sd_bus_message_dump
|
| | |
| |
| |
| | |
Fixes #14640.
|
| | | |
|
| | | |
|
| |/
|
|
| |
attributes for that
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The combination of sd_netlink_message_enter_container() and
sd_netlink_message_read_string() only reads the last element if the attribute is
duplicated, such a situation easily happens for IFLA_ALT_IFNAME.
The function introduced here reads all matched attributes.
|
| |
|
|
|
|
|
|
| |
Don't reset the conflict counter when trying a new pseudo random
address, so that after trying 10 addresses the londer timeout is used in
accordance with the RFC
Fixes #14299.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows marking messages that contain "sensitive" data with a flag.
If it's set then the messages are erased from memory when the message is
freed.
Similar, a flag may be set on vtable entries: incoming/outgoing message
matching the entry will then automatically be flagged this way.
This is supposed to be an easy method to mark messages containing
potentially sensitive data (such as passwords) for proper destruction.
(Note that this of course is only is as safe as the broker in between is
doing something similar. But let's at least not be the ones at fault
here.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for watching for process exits via Linux new pidfd
concept. This makes watching processes and killing them race-free if
properly used, fixing a long-standing UNIX misdesign.
This patch adds implicit and explicit pidfd support to sd-event: if a
process shall be watched and is specified by PID we will now internally
create a pidfd for it and use that, if available. Alternatively a new
constructor for child process event sources is added that takes pidfds
as input.
Besides mere watching of child processes via pidfd two additional
features are added:
→ sd_event_source_send_child_signal() allows sending a signal to the
process being watched in the safest way possible (wrapping
the new pidfd_send_signal() syscall).
→ sd_event_source_set_child_process_own() allows marking a process
watched for destruction as soon as the event source is freed. This is
currently implemented in userspace, but hopefully will become a kernel
feature eventually.
Altogether this means an sd_event_source object is now a safe and stable
concept for referencing processes in race-free way, with automatic
fallback to pre-pidfd kernels.
Note that this patch adds support for this only to sd-event, not to PID
1. That's because PID 1 needs to use waitid(P_ALL) for reaping any
process that might get reparented to it. This currently semantically
conflicts with pidfd use for watching processes since we P_ALL is
undirected and thus might reap process earlier than the pidfd notifies
process end, which is hard to handle. The kernel will likely gain a
concept for excluding specific pidfds from P_ALL watching, as soon as
that is around we can start making use of this in PID 1 too.
|
| |
|
|
| |
sd_dhcp_raw_option and sd_dhcp_option are essentially equivalent.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implementes https://tools.ietf.org/html/rfc2132
```
[DHCPServer]
SendRawOption=26:uint32:1400
SendRawOption=23:uint8:10
```
Frame 448: 350 bytes on wire (2800 bits), 350 bytes captured (2800 bits) on interface 0
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.5.1, Dst: 192.168.5.11
User Datagram Protocol, Src Port: 67, Dst Port: 68
Dynamic Host Configuration Protocol (ACK)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x71f8de9d
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.5.11
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: 1e:04:f8:b8:2f:d4 (1e:04:f8:b8:2f:d4)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (ACK)
Length: 1
DHCP: ACK (5)
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (3600s) 1 hour
Option: (1) Subnet Mask (255.255.255.0)
Length: 4
Subnet Mask: 255.255.255.0
Option: (3) Router
Length: 4
Router: 192.168.5.1
Option: (6) Domain Name Server
Length: 4
Domain Name Server: 192.168.5.1
Option: (42) Network Time Protocol Servers
Length: 4
Network Time Protocol Server: 192.168.5.1
Option: (101) TCode
Length: 13
TZ TCode: Europe/Berlin
Option: (43) Vendor-Specific Information
Length: 9
Value: 1701311a0431343030
Option: (54) DHCP Server Identifier (192.168.5.1)
Length: 4
DHCP Server Identifier: 192.168.5.1
Option: (255) End
Option End: 255
```
|
| |
|
|
| |
Add network delay to a interface
|
| |
|
|
|
|
|
|
|
| |
sd-netlink is not public yet, so we can change the interface.
I did not touch interfaces of functions like sd_netlink_wait() and
sd_rtnl_message_new_link() which do not modify the object that is passed in,
because in the future we might want to change the code to e.g. take a
reference to the parent object or otherwise require a non-const reference.
|
| |\
| |
| | |
network: wifi ssid support with nl80211
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
|/| |
network: DHCPv4 client- add support to send arbitary option and data
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
Used to manipulate entries in the kernel's nexthop tables.
Example:
```
[NextHop]
Id=3
Gateway=192.168.5.1
```
|
