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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
There's no point in caching this. Let's always get this directly from
sysfs, so that we can never get out-of-date data here (after all this is
going to be cheap, and people might overmount it or so)
Let's not cache the uname(), it's very cheap to get it, and just means
we might get out of sync with what is current. After all, the data might
change IRL, due to setarch and stuff.
This way we can take benefit of the correct block device locking we just
added.
I was thinking whether to instead pull in a regular
systemd-makefs@.service instance, but I couldn't come up with a reason
to, and thus opted for just doing the minimal patch and just replacing
the simply mkfs calls.
Fixes: #10179
Replaces: #13162
Much like systemd.condition-needs-update= this new switch allows
overriding of a unit file condition, but this time its
ConditionFirstBoot=.
Usecase is also primarily debugging, but could be useful for other
schemes too.
Condition checks shouldn't log loudly, since they run all the time.
Let's make things debuggable, by keeping the messages in LOG_DEBUG in,
but don't make more noise than necessary.
We should do this check first since it is done on the string itself
without any conditioning of system state otherwise. It is a weird to do
this test only if /etc is read-only.
Debian Policy encourages to preserve timestamps whenever possible in the
tarballs, thus stable release updates of systemd usually do not bump NEWS file
timestamp. And thus time-epoch remains the same for the lifetime of a release.
It would be better, if each new stable release rebuild of systemd would bump
the time epoch a bit. But at the same time remain
reproducible. SOURCE_DATE_EPOCH is an environmnet variable defined for this
purpose. Thus if available, prefer that, instead of the NEWS file modification
time.
For example, on Debian/Ubuntu under the reproducible builds the
SOURCE_DATE_EPOCH is set to the timestamp from the packaging metadata, thus it
is incremented on every new stable release update, whilst preserving
reproducible builds capability.
Reference: https://reproducible-builds.org/docs/timestamps/
