summaryrefslogtreecommitdiffstats
path: root/src/systemd (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* | radv: introduce sd_radv_is_running()Yu Watanabe2020-07-201-0/+1
|/
* udevadm: beef up deprecation log warningLennart Poettering2020-07-141-0/+5
| | | | | | | | Let's add a catalog entry explaining further details. Most importantly though: talk to PID 1 directly, via the private D-Bus socket, so that this actually works correctly during early boot, where D-Bus is not around.
* all: fix minor typosYuri Chornoivan2020-07-071-1/+1
| | | | | | [thaller@redhat.com: original patch by Yuri, extracted from [1]] [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
* Revert "network: Don't send RA with zero router lifetime when restarting radv"Yu Watanabe2020-07-071-2/+1
| | | | This reverts commit d469cea3bde53bc39317c8b433c825bb4790cbe5.
* network: Don't send RA with zero router lifetime when restarting radvMichael Marley2020-07-071-1/+2
| | | | | | | | | | | | | | While investigating https://github.com/systemd/systemd/issues/16356, I discovered that networkd stops the radv service before adding or updating prefixes and then starts it again. This causes networkd to send an RA with a router lifetime of zero, causing the routes to flap on systems receiving the RA for a fraction of a second before radv is started again and proper RAs are sent. That has the potential to cause issues with latency-sensitive traffic like gaming or VoIP. This patch adds a boolean argument to the sd_radv_stop() function to control this behavior. The zero lifetime RA is still sent whenever radv is actually being stopped, but when it is being restarted for a prefix update (from networkd-dhcp6.c), the final RA is no longer sent to avoid the route flapping.
* pid1: warn if people use User=nobody (#16293)Lennart Poettering2020-06-261-0/+4
|
* sd-network: drop unused functionsYu Watanabe2020-06-231-10/+0
|
* network: clean-up DHCP lease server data configurationLennart Poettering2020-06-182-14/+2
| | | | | | | | | | | | | | | | | | | | | | | | This is an attempt to clean up the POP3/SMTP/LPR/… DHCP lease server data logic in networkd. This reduces code duplication and fixes a number of bugs. This removes any support for collecting POP3/SMPT/LPR servers acquired via local DHCP client releases since noone uses that, and given how old these protocols are I doubt this will change. It keeps support for configuring them for the dhcp server however. The differences between the DNS/NTP/SIP/POP3/SMTP/LPR configuration logics are minimized. This removes the relevant symbols from sd-network.h (which is an internal API only at this point after all). This is unfortunately not well test, given the old code for this had barely any tests. But the new code should not perform worse at least, and allow us to release, since it corrects some interfaces visible in the .network configuration format. Fixes: #15943
* sd-network: Introduce APIs to get DHCP6 DUIDSusant Sahani2020-06-101-0/+3
|
* network: DHCP6 - introduce DHCP6 DUID to stringSusant Sahani2020-06-101-0/+3
|
* sd-network: Introduce API to get DHCPv6 IAIDSusant Sahani2020-06-091-0/+3
|
* dhcp6: Provide method to access IAIDSusant Sahani2020-06-091-0/+3
|
* sd-network: Introduce API to access DHCP4 client IDSusant Sahani2020-06-081-0/+3
|
* sd-dhcp-client: add sd_dhcp_client_id_to_string()Marc-André Lureau2020-06-041-0/+2
| | | | Add a human-friendly pretty-printer for client ID.
* sd-dhcp-server: notify callback on lease changedMarc-André Lureau2020-06-041-0/+4
|
* sd-dhcp-server: add sd_dhcp_server_set_callback()Marc-André Lureau2020-06-041-0/+4
|
* Merge pull request #15884 from ssahani/dhcpv6-vendorYu Watanabe2020-06-013-2/+6
|\ | | | | DHCPv6: Introduce vendor specific
| * sd-dhcp6: Introduce vendor specific informationSusant Sahani2020-05-293-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: 8415 21.17. Vendor-specific Information Option This option is used by clients and servers to exchange vendor- specific information. The format of the Vendor-specific Information option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_OPTS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . vendor-option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 30: Vendor-specific Information Option Format option-code OPTION_VENDOR_OPTS (17). option-len 4 + length of vendor-option-data field. enterprise-number The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4-octet field containing an unsigned integer. vendor-option-data Vendor options, interpreted by vendor-specific code on the clients and servers. A variable-length field (4 octets less than the value in the option-len field). The definition of the information carried in this option is vendor specific. The vendor is indicated in the enterprise-number field. Use of vendor-specific information allows enhanced operation, utilizing additional features in a vendor's DHCP implementation. A DHCP client that does not receive requested vendor-specific information will still configure the node's IPv6 stack to be functional. The vendor-option-data field MUST be encoded as a sequence of code/length/value fields of format identical to the DHCP options (see Section 21.1). The sub-option codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Each of the sub-options is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-opt-code | sub-option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 31: Vendor-specific Options Format sub-opt-code The code for the sub-option. A 2-octet field. sub-option-len An unsigned integer giving the length of the sub-option-data field in this sub-option in octets. A 2-octet field. sub-option-data The data area for the sub-option. The length, in octets, is specified by sub-option-len. Multiple instances of the Vendor-specific Information option may appear in a DHCP message. Each instance of the option is interpreted according to the option codes defined by the vendor identified by the Enterprise Number in that option. Servers and clients MUST NOT send more than one instance of the Vendor-specific Information option with the same Enterprise Number. Each instance of the Vendor-specific Information option MAY contain multiple sub-options. A client that is interested in receiving a Vendor-specific Information option: - MUST specify the Vendor-specific Information option in an Option Request option. - MAY specify an associated Vendor Class option (see Section 21.16). - MAY specify the Vendor-specific Information option with appropriate data. Servers only return the Vendor-specific Information options if specified in Option Request options from clients and: - MAY use the Enterprise Numbers in the associated Vendor Class options to restrict the set of Enterprise Numbers in the Vendor-specific Information options returned. - MAY return all configured Vendor-specific Information options. - MAY use other information in the packet or in its configuration to determine which set of Enterprise Numbers in the Vendor-specific Information options to return.
* | sd-dhcp: clean-up of DHCP lease server codeLennart Poettering2020-05-302-14/+15
|/ | | | | | | | | | | | | | | | | | This is an attempt to clean-up the DHCP lease server type code a bit. We now strictly use the same enum everywhere, and store server info in an array. Moreover, we use the same nomenclature everywhere. This only makes the changes in the sd-dhcp code. The networkd code is untouched so far (but should be fixed up like this too. But it's more complicated since this would then touch actual settings in .network files). Note that this also changes some field names in serialized lease files. But given that these field names have not been part of a released version of systemd yet, such a change should be ok. This is pure renaming/refactoring, shouldn't actually change any behaviour.
* Merge pull request #15911 from poettering/unit-name-tightenYu Watanabe2020-05-291-0/+5
|\ | | | | pid1: improve logging when we encounter a path that is too long to be converted into a mount unit name
| * core: improve log messages when we cannot process a mount pointLennart Poettering2020-05-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Whenever we pick up a new line in /proc/self/mountinfo and want to synthesize a new mount unit from it, let's say which one it is. Moreover, downgrade the log message when we encounter a mount point with an overly long name to LOG_WARNING, since it's generally fine to ignore such mount points. Also, attach a catalog entry to explain the situation further. Prompted-By: #15221
* | sd-path: drop "-dir" and "-path" suffixes from path enumsLennart Poettering2020-05-281-24/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clean up the naming of the sd-path enums. Previously, the more recently added fields where named in the form SD_PATH_xyz_DIR and SD_PATH_xyz_PATH, while the older fields where called just SD_PATH_xyz and SD_PATH_SEARCH_xyz. Let's clean this up, to come to a more unified way how we name this stuff. I opted to stick to the old naming, i.e. dropthe suffixes. It's a bit of a bike-shedding question of course, but I think there's a good reason to avoid the additional DIR and PATH suffixes: the enum prefix contains "PATH" anyway (i.e. "SD_PATH_"), so including PATH twice in each name is redundant. Moreover, the key difference between the enums with the "dir" and the "path" in the name is that the latter are *seach* paths, and I think this is better emphasized by sticking to the "SEARCH" in the name. Moreover dropping the suffixes makes the identifiers a lot shorter, in particular in the "systemd-path" list output. And that's always good. This means the naming pkgconfig file and in sd-path slightly deviate (though the mapping is very simple), but I think that's OK, given that this is developer facing and not user facing.
* | Merge pull request #15906 from keszybz/busctl-stdout-stderrLennart Poettering2020-05-261-0/+7
|\ \ | | | | | | Make busctl stdout/stderr split consistent
| * | sd-bus: make name validation functions publicZbigniew Jędrzejewski-Szmek2020-05-251-0/+7
| |/ | | | | | | | | | | | | | | | | | | Those are fairly trivial to reimplement, but any non-trivial user of sd-bus is likely to need them. So let's expose them to save everyone the trouble. I'm keeping the internal functions and making the public ones thin wrappers, because for the internal uses we don't need the additional asserts, and also we can't expose _pure_ annotation easily, and dropping it would likely make the compiled code a bit less efficient.
* / sd-dhcp6: constify output arguments in get_{ntp,nds}_addrZbigniew Jędrzejewski-Szmek2020-05-261-3/+2
|/ | | | This matches what we do for ipv4 and is in general better.
* Merge pull request #15274 from ssahani/network-issue-9610Zbigniew Jędrzejewski-Szmek2020-05-201-0/+3
|\ | | | | DHCP4: Allow lease time to be set when missing from offer
| * sd-dhcpv4: Allow to configure lease lifetimeSusant Sahani2020-05-201-0/+3
| |
* | sd-network: DHCPv6 - Add support to send vendor class dataSusant Sahani2020-05-201-1/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ``` 21.16. Vendor Class Option This option is used by a client to identify the vendor that manufactured the hardware on which the client is running. The information contained in the data area of this option is contained in one or more opaque fields that identify details of the hardware configuration. The format of the Vendor Class option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . vendor-class-data . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 28: Vendor Class Option Format option-code OPTION_VENDOR_CLASS (16). option-len 4 + length of vendor-class-data field. enterprise-number The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4-octet field containing an unsigned integer. vendor-class-data The hardware configuration of the node on which the client is running. A variable-length field (4 octets less than the value in the option-len field). The vendor-class-data field is composed of a series of separate items, each of which describes some characteristic of the client's hardware configuration. Examples of vendor-class-data instances might include the version of the operating system the client is running or the amount of memory installed on the client. Each instance of vendor-class-data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | vendor-class-len | opaque-data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ Figure 29: Format of vendor-class-data Field The vendor-class-len field is 2 octets long and specifies the length of the opaque vendor-class-data in network byte order. Servers and clients MUST NOT include more than one instance of OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance of OPTION_VENDOR_CLASS can carry multiple vendor-class-data instances. ```
* sd-network: DHCPv6 - add support to send userclass optionSusant Sahani2020-05-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sd-network: DHCPv6 - add support to send userclass option 21.15. User Class Option The User Class option is used by a client to identify the type or category of users or applications it represents. The format of the User Class option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_USER_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . user-class-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26: User Class Option Format option-code OPTION_USER_CLASS (15). option-len Length of user-class-data field. user-class-data The user classes carried by the client. The length, in octets, is specified by option-len. The information contained in the data area of this option is contained in one or more opaque fields that represent the user class or classes of which the client is a member. A server selects configuration information for the client based on the classes identified in this option. For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. The user class information carried in this option MUST be configurable on the client. The data area of the User Class option MUST contain one or more instances of user-class-data information. Each instance of user-class-data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | user-class-len | opaque-data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ Figure 27: Format of user-class-data Field
* Merge pull request #15804 from poettering/hostnamed-instant-part1Zbigniew Jędrzejewski-Szmek2020-05-181-0/+1
|\ | | | | four likely safe commits split out of #15624
| * sd-bus: introduce new SD_BUS_VTABLE_ABSOLUTE_OFFSET vtable flagLennart Poettering2020-05-131-0/+1
| | | | | | | | | | | | | | | | When set, the offset specified for the vtable entry is passed to the handler as-is, and is not added to the userdata pointer. This is useful in case methods/properties are mixed on the same vtable, that expect to operate relative to some object in memory and that expect pointers to absolute memory, or that just want a number passed.
* | sd-dhcp-server: some function prototype fix-upsLennart Poettering2020-05-141-9/+9
|/ | | | | | | | | Let's use size_t for numbers of entries in memory. Let's use const wherever appropriate. Drop `_server` suffix from function name where we don't have it for similar other cases.
* DHCP client: make SendOption work for DHCPv6 too.Andrew Doran2020-05-112-0/+40
|
* sd-bus: Add a nicer way of specifying sd-bus vtable method argumentsDaan De Meyer2020-05-061-0/+118
| | | | | SD_BUS_NAMES_WITH_ARGS is a less error-prone way of specifying D-Bus method arguments.
* Introduce sd_notify_barrierKumar Kartikeya Dwivedi2020-04-301-0/+13
| | | | | | | | | | | | | | | This adds the sd_notify_barrier function, to allow users to synchronize against the reception of sd_notify(3) status messages. It acts as a synchronization point, and a successful return gurantees that all previous messages have been consumed by the manager. This can be used to eliminate race conditions where the sending process exits too early for systemd to associate its PID to a cgroup and attribute the status message to a unit correctly. systemd-notify now uses this function for proper notification delivery and be useful for NotifyAccess=all units again in user mode, or in cases where it doesn't have a control process as parent. Fixes: #2739
* sd-bus: Add sd_bus_query_sender_creds/privilege docsDaan De Meyer2020-04-281-2/+2
|
* dhcp6: make string argument to sd_dhcp6_client_set_request_mud_url() constThomas Haller2020-04-241-1/+1
|
* Merge pull request #15530 from ssahani/lpr-dhcpv4-option-9Zbigniew Jędrzejewski-Szmek2020-04-234-0/+7
|\ | | | | network: add support to DHCPv4 server/client option 9 LPR
| * sd-network: Add support to retrive LPR serversSusant Sahani2020-04-221-0/+3
| |
| * sd-network: DHCPv4 Add support to send and receive LPR servers.Susant Sahani2020-04-223-0/+4
| |
* | tree-wide: fix spelling errorsFrantisek Sumsal2020-04-211-1/+1
|/ | | | | | Based on a report from Fossies.org using Codespell. Followup to #15436
* Merge pull request #15314 from keszybz/network-server-access-functionsLennart Poettering2020-04-212-1/+19
|\ | | | | Define network server access functions
| * sd-dhcp-server: add a meta-setter to simplify setting of server listsZbigniew Jędrzejewski-Szmek2020-04-101-1/+9
| |
| * sd-dhcp-lease: add a meta-getter to simplify querying of server listsZbigniew Jędrzejewski-Szmek2020-04-101-0/+10
| |
* | headers: get rid of pointless /* deprecated */ commentZbigniew Jędrzejewski-Szmek2020-04-172-6/+6
| | | | | | | | | | The _sd_deprecated_ annotation gives it all away, and the comment adds no additional value.
* | sd-login: get rid of seat_can_multi_session()Zbigniew Jędrzejewski-Szmek2020-04-171-1/+1
| | | | | | | | | | | | | | | | | | Follow-up for fa2cf64a917d31605d40d34e98ce9e2e066064fa. Backwards-compat is retained. A short note is added in docs, in case people see sd_seat_can_multi_session() mentioned somewhere and wonder what happened to it. Also see https://github.com/systemd/systemd/pull/15337#issuecomment-610369404.
* | sd-bus: Use pointer syntax for sd_bus_set_exec argv parameterDaan De Meyer2020-04-111-1/+1
|/
* Merge pull request #15352 from poettering/user-group-name-valdity-reworkLennart Poettering2020-04-091-0/+3
|\ | | | | user/group name validity rework
| * user-util: rework how we validate user namesLennart Poettering2020-04-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reworks the user validation infrastructure. There are now two modes. In regular mode we are strict and test against a strict set of valid chars. And in "relaxed" mode we just filter out some really obvious, dangerous stuff. i.e. strict is whitelisting what is OK, but "relaxed" is blacklisting what is really not OK. The idea is that we use strict mode whenver we allocate a new user (i.e. in sysusers.d or homed), while "relaxed" mode is when we process users registered elsewhere, (i.e. userdb, logind, …) The requirements on user name validity vary wildly. SSSD thinks its fine to embedd "@" for example, while the suggested NAME_REGEX field on Debian does not even allow uppercase chars… This effectively liberaralizes a lot what we expect from usernames. The code that warns about questionnable user names is now optional and only used at places such as unit file parsing, so that it doesn't show up on every userdb query, but only when processing configuration files that know better. Fixes: #15149 #15090
* | sd-lldp: Add support to receive MUDSusant Sahani2020-04-071-0/+4
|/
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 04:41:45 +0100