IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If the user does not specify a config file to use, ukify will try looking for one at {/run,/etc,/usr/local/lib,/usr/lib}/systemd/ukify.conf in order and then use the first one found. Also made sure the --config input is a pathlib.Path by specifying its type in its CONFIG_ITEMS entry.
Big cheers to Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> for helping!
We basically parsed the RFC3339 format already, except with a space:
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
so now we handle both
2012-11-23 11:12:13.456
2012-11-23T11:12:13.456
as equivalent.
Parse directly-suffixed Z and +05:30 timezones as well:
2012-11-23T11:12:13.456Z
2012-11-23T11:12:13.456+02:00
as they're both defined by RFC3339.
We do /not/ allow z or t; the RFC says
NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
syntax may alternatively be lower case "t" or "z" respectively.
This date/time format may be used in some environments or contexts
that distinguish between the upper- and lower-case letters 'A'-'Z'
and 'a'-'z' (e.g. XML). Specifications that use this format in
such environments MAY further limit the date/time syntax so that
the letters 'T' and 'Z' used in the date/time syntax must always
be upper case. Applications that generate this format SHOULD use
upper case letters.
We /are/ in a case-sensitive environment, neither are in wide-spread
use, and "z" poses an issue of whether "todayz" should be the same
as "todayZ" ("today UTC") or an error (it should be an error).
Fractional seconds are limited to six digits (they're nominally
time-secfrac = "." 1*DIGIT
), since we only support 1µs-resolution timestamps, and limit to six
digits in our other sub-second formats.
Parsing
2012-11-23T11:12
is an extension two ways (no seconds, no timezone),
mirroring our "canonical" format.
Fixes#5194
The example was supposed to show how
machine-id/new/machine-id --app-specific/show --app-specific tie together, but
the verb was ommitted.
I also extended the explanation a bit and used long option form in the first
example for more clarity. In the second, more complicated example, the
one-letter form is used for brevity.
Noticed in post-review:
b37e8184a5 (r1315678438)
I'm keeping this as a separate commit. It is the first time version
information is manually added after 6a73a4f7c466887a03c9939300ba6864203b1b3f
and we might want to revert this later.
If it is null, we get the 'base' param unchanged:
$ build/systemd-id128 show 00000000000000000000000000000001 \
--app-specific=00000000000000000000000000000000
00000000000000000000000000000001
This is not good, because it breaks our promise that the base (usually either
machine-id or boot-id) cannot be derived from the result. Some application
using the library could use a null app id, inadvertently exposing the machine
or boot id. (This could happen because of forgotten initialization, or maybe
because the app id is configurable, and the user configures it wrongly.)
Note: the other way the secret is not exposed:
$ build/systemd-id128 show 00000000000000000000000000000000 \
--app-specific=00000000000000000000000000000002
4f63080959264900b0d88d999dae2d3a
Normally systemd would not allow a null machine-id or boot-id, but we can let
the user do the calculation that if they want to.
https://github.com/systemd/systemd/issues/27514 requested this functionality
among other things, but it is already implemented. The man page was also
missing 'show' in the synopsis, so add that, along with an example.
This tries to add information about when each option was added. It goes
back to version 183.
The version info is included from a separate file to allow generating it,
which would allow more control on the formatting of the final output.
The notice in the man page is removed and the tool is moved into the $PATH.
A compat symlink is provided.
It is fairly widely used now, and realistically we need to keep backwards
compat or people will be very unhappy.
New directive `NFTSet=` provides a method for integrating network configuration
into firewall rules with NFT sets. The benefit of using this setting is that
static network configuration or dynamically obtained network addresses can be
used in firewall rules with the indirection of NFT set types. For example,
access could be granted for hosts in the local subnetwork only. Firewall rules
using IP address of an interface are also instantly updated when the network
configuration changes, for example via DHCP.
This option expects a whitespace separated list of NFT set definitions. Each
definition consists of a colon-separated tuple of source type (one of
"address", "prefix", or "ifindex"), NFT address family (one of "arp", "bridge",
"inet", "ip", "ip6", or "netdev"), table name and set name. The names of tables
and sets must conform to lexical restrictions of NFT table names. The type of
the element used in the NFT filter must match the type implied by the
directive ("address", "prefix" or "ifindex") and address type (IPv4 or IPv6)
as shown type implied by the directive ("address", "prefix" or "ifindex") and
address type (IPv4 or IPv6) must also match the set definition.
When an interface is configured with IP addresses, the addresses, subnetwork
masks or interface index will be appended to the NFT sets. The information will
be removed when the interface is deconfigured. systemd-networkd only inserts
elements to (or removes from) the sets, so the related NFT rules, tables and
sets must be prepared elsewhere in advance. Failures to manage the sets will be
ignored.
/etc/systemd/network/eth.network
```
[DHCPv4]
...
NFTSet=prefix:netdev:filter:eth_ipv4_prefix
```
Example NFT rules:
```
table netdev filter {
set eth_ipv4_prefix {
type ipv4_addr
flags interval
}
chain eth_ingress {
type filter hook ingress device "eth0" priority filter; policy drop;
ip saddr != @eth_ipv4_prefix drop
accept
}
}
```
```
$ sudo nft list set netdev filter eth_ipv4_prefix
table netdev filter {
set eth_ipv4_prefix {
type ipv4_addr
flags interval
elements = { 10.0.0.0/24 }
}
}
```
This reverts commits 89e73ce86fb115c2e319bf9f28b63efad2975495 and
543d2a4d45ba199a62c87b3bf69dfd4ff55abf0c.
The commit assign "custom" to fixed DUID type 5. When making DUID fully
configurable, the type number should be also configurable. Also, the
fully custom DUID should be acceptable for DHCPv4.
- add reference to the service unit in the man page,
- fix several indentation and typos,
- replace '(uint64_t) -1' with 'UINT64_MAX',
- drop unnecessary 'continue'.
- rename TCPRetransmissionTimeOutSec= -> TCPRetransmissionTimeoutSec,
- refuse infinity,
- fix the input value verifier (USEC_PER_SEC -> USEC_PER_MSEC),
- use DIV_ROUND_UP() when assigning the value.
Follow-ups for 1412d4a4fea234fd2afda26b1241cd700246a672.
Closes#28898.
The kernel default for tmpfs mounts is rwxrwxrwt, i.e. world-writable with the
sticky bit set. This makes sense for /tmp and /var/tmp, but less so for other
directories. Users will not use systemd-mount to mount /tmp and /var/tmp, so
the existing behaviour is surprising. The defaults are overriden to the
same defaults we use for "internal tmpfs mounts", i.e. no sticky bit, nosuid,
nodev, and limits of size=10%, nr_inodes=400k.
--tmpfs is new, so we can modify the behaviour without breaking compatibility.
