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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This patch add support to enables to send User Class option code 77
RFC 3004.
This option MAY carry multiple User Classes.
The format of this option is as follows:
Code Len Value
+-----+-----+--------------------- . . . --+
| 77 | N | User Class Data ('Len' octets) |
+-----+-----+--------------------- . . . --+
where Value consists of one or more instances of User Class Data.
Each instance of User Class Data is formatted as follows:
UC_Len_i User_Class_Data_i
+--------+------------------------ . . . --+
| L_i | Opaque-Data ('UC_Len_i' octets) |
+--------+------------------------ . . . --+
UserClass=
A DHCPv4 client can use UserClass option to identify the type or category of user or applications
it represents. The information contained in this option is an string that represents the user class
of which the client is a member. Each class sets an identifying string of information to be used by the DHCP service to classify clients. Takes a whitespace-separated list.
UserClass= hello world how are you
Closes: RFC: #5134
if we lack privs to create device nodes that's fine, and creating
/run/systemd/inaccessible/chr or /run/systemd/inaccessible/blk won't
work then. Document this in longer comments.
Fixes: #4484
Yes, the output is sometimes annyoing, but /dev/null is not the right
place...
I figure this redirection was left in from some debugging session, let's
fix it, and make the setup_basic_environment invocation like in all
other test scripts.
If dbus.service starts earlier than the dynamic user systemd-timesync
is realized, then the dbus policy file for timesyncd does not loaded
and timesyncd fails to request name.
To support such case, try to reload dbus configuration when requesting
name fails.
This is based on @jsynacek's patch from #8837, but adds the new URL in
two flavours instead of replacing the old, also making @keszybz happy.
Replaces: #8837
Before this, `signal_from_string()` accepts simple signal name
or RTMIN+n. This makes the function also accept RTMIN, RTMAX,
and RTMAX-n.
Note that RTMIN+0 is equivalent to RTMIN, and RTMAX-0 is to RTMAX.
This also fixes the integer overflow reported by oss-fuzz #8064.
https://oss-fuzz.com/v2/testcase-detail/5648573352902656
Nested KVM is very flaky as we learnt from our CI. Hence, let's avoid
KVM whenever we detect we are already running inside of KVM.
Maybe one day nested KVM is fixed, at which point we can turn this on
again, but for now let's simply avoid nested KVM, since reliable CI is
more important than quick CI, I guess.
And yes, avoiding KVM for our qemu runs does make things substantially
slower, but I think it's not a complete loss.
Inspired by @evverx' findings in:
https://github.com/systemd/systemd/pull/8701#issuecomment-380213302
Our CODING_STYLE document suggests to suffix all paths referring to dirs
rather than regular files with a "/" in our docs and log messages.
Update file-hierarchy(7) to do just that.
No other changes.
We document this further down in the text, but let's also list this
early on, where we mention the FHS as major influence too, so that it is
clear we incorporate all that thinking.
The leak can be reproduced by running systemd-path --suffix .tmp under valgrind or asan:
$ ./build/systemd-path --suffix .tmp search-binaries
/usr/local/bin/.tmp:/usr/bin/.tmp:/usr/local/sbin/.tmp:/usr/sbin/.tmp:/home/vagrant/.local/bin/.tmp:/home/vagrant/bin/.tmp
=================================================================
==19177==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 56 byte(s) in 1 object(s) allocated from:
*0 0x7fd6adf72850 in malloc (/lib64/libasan.so.4+0xde850)
*1 0x7fd6ad2b93d2 in malloc_multiply ../src/basic/alloc-util.h:69
*2 0x7fd6ad2bafd2 in strv_split ../src/basic/strv.c:269
*3 0x7fd6ad42ba67 in search_from_environment ../src/libsystemd/sd-path/sd-path.c:409
*4 0x7fd6ad42bffe in get_search ../src/libsystemd/sd-path/sd-path.c:482
*5 0x7fd6ad42c55b in sd_path_search ../src/libsystemd/sd-path/sd-path.c:607
*6 0x7fd6ad42b3a2 in sd_path_home ../src/libsystemd/sd-path/sd-path.c:348
*7 0x55f59c65ebea in print_home ../src/path/path.c:97
*8 0x55f59c65f157 in main ../src/path/path.c:177
*9 0x7fd6abaea009 in __libc_start_main (/lib64/libc.so.6+0x21009)
Indirect leak of 68 byte(s) in 5 object(s) allocated from:
*0 0x7fd6adf72850 in malloc (/lib64/libasan.so.4+0xde850)
*1 0x7fd6abb5f689 in strndup (/lib64/libc.so.6+0x96689)
Indirect leak of 25 byte(s) in 1 object(s) allocated from:
*0 0x7fd6adf72850 in malloc (/lib64/libasan.so.4+0xde850)
*1 0x7fd6abb5f689 in strndup (/lib64/libc.so.6+0x96689)
*2 0x6c2e2f746e617266 (<unknown module>)
SUMMARY: AddressSanitizer: 149 byte(s) leaked in 7 allocation(s).
