resolve: reject host names with leading or trailing dashes in /etc/hosts
https://tools.ietf.org/html/rfc1035#section-2.3.1 says (approximately)
that only letters, numbers, and non-leading non-trailing dashes are allowed
(for entries with A/AAAA records). We set no restrictions.
hosts(5) says:
> Host names may contain only alphanumeric characters, minus signs ("-"), and
> periods ("."). They must begin with an alphabetic character and end with an
> alphanumeric character.
nss-files follows those rules, and will ignore names in /etc/hosts that do not
follow this rule.
Let's follow the documented rules for /etc/hosts. In particular, this makes us
consitent with nss-files, reducing surprises for the user.
I'm pretty sure we should apply stricter filtering to names received over DNS
and LLMNR and MDNS, but it's a bigger project, because the rules differ
depepending on which level the label appears (rules for top-level names are
stricter), and this patch takes the minimalistic approach and only changes
behaviour for /etc/hosts.
Escape syntax is also disallowed in /etc/hosts, even if the resulting character
would be allowed. Other tools that parse /etc/hosts do not support this, and
there is no need to use it because no allowed characters benefit from escaping.
Do not treat various errors (missing hostname, invalid address) as fatal,
just warn and continue. /etc/hosts is written by humans and we should not
reject the whole file just because a singly entry is not to our liking.
Handle comments as described in hosts(5):
everything from the comment character until the end of the line should be
ignored.
When using networkd we currently have no way of ensuring that static
neighbor entries are set when our link comes up. This change adds a new
section to the network definition that allows multiple static neighbors
to be set on a link.
This allows us to convey that we are performing multiple link
configuration changes in parallel. This is needed to support configuring
neighbors while simultaneously configuring addresses and routes.
This will be useful to assert that our static route configuration always
happens after address configuration once our individual configure state
goes away.
travis: mount tmpfs on /tmp before running the tests
To judge from https://api.travis-ci.org/v3/job/465547774/log.txt,
overlayfs on Travis CI is having trouble delivering inotify events,
which is why `test-path` and `test-event` are failing there.
Turns out some tests like `test-execute` are tightly coupled with
systemd as PID1 (which should be fixed of course). In the meantime,
let's see how it goes.
Patches are shown on github with a fixed width (no matter how wide the window
is). When line numbers are high (we have some files with 5 digit line numbers),
the diff does not fit, and horizontal scrolling must be used when viewing the
patch. This is super annoying. Let's reduce the width a bit. I think 109 is
still very wide, but at least the github issue should be alleviated.
swap: always add in extras when we load a swap unit
Much like for the mount units we need fields such as the slice
initialized by the time we activate the swap, hence when the kernel
let's us know about a new swap that appeared we need to initialize the
slice in any Swap object we allocated for that right-away, even if we
can't read the real unit file for the swap device.
mount: flush out cycle state on DEAD→MOUNTED only, not the other way round
For services (and other units) we generally follow the rule that at the
beginning of each cycle, i.e. when the INACTIVE/FAILED state is left for
ACTIVATING/ACTIVE we flush out various state variables. Mount units
handled this differently so far when the unit state change was effected
outside of systemd: in that case these variables would be flushed out
when going back to INACTIVE/FAILED already.
Let's fix that, and flush out this state always during the activating
transition, not during the deactivating transition.
We never know what the changes triggered by mount_set_state() do to the
unit. Let's be safe and copy the device path into our set, so that we
are safe against that.
mount: when the kernel reports a mount to be established reset all kinds of load failures
It doesn't matter what kind of precise failure we had earlier with
loading the unit, let's report that it loaded successfully now, after
all the kernel is an OK source for that, like any other.
mount: regenerate all deps whenever a mount's parameters changes
Whenever we notice a change on an existing /proc/self/mountinfo line,
let's update the deps generated from it. For that, let's flush out the
old deps generated this way, and add in the new ones.
This takes benefit of the fact that today (unlike a comment this patch
removes says) we can remove deps in a somewhat reasonable way.
mount: when allocating a Mount object based on /proc/self/mountinfo mark it so
Let's set 'from_proc_self_mountinfo' right away, since we know its from
there. This is important so that when the load queue is dispatched (and
thus mount_load() called) this
fact is already known.
mount: let mount_add_extras() take care of remote-fs.target deps
In a previous commit we added logic that mount_add_extras() (or more
precisely mount_add_default_dependencies()) adds in dependencies on
remote-fs.target and local-fs.target, hence we can drop this from
mount_setup_new_unit() and let the usual load queue dispatching take
care of this.
Let's initialize two fields with free_and_strdup() rather than directly
with strdup(). The fields should not be initialized so far, but it's
still nicer to be prepared for futzre code changes and always free
what's stored before replacing it.
mount: don't propagate errors from mount_setup_unit() further up
If we can't process a specific line in /proc/self/mountinfo we should
log about it (which we do), but this should not affect other lines, nor
further processing of mount units. Let's keep these failures local.
mount: make sure mount_add_extras() is always invoked when we load a mount unit
We need to make sure that the slice property is initialized whenever
mount_load() is invoked, even if we fail to load things properly off
disk. This is important since we generally don't allow changing the
slice after a unit has been started. But given that we must track the
state of external objects with mount units we must hence initialize the
property no matter what.
mount: set up local-fs.target/remote-fs.target deps in mount_add_default_dependencies() too
This deps are very similar to the -pre deps, hence establish them at the
same place, in particular as they should only be generated if default
deps are on.
This allows us to later on remove similar code that adds in these deps
whenever /proc/self/mountinfo changes.
resolved: add new helper for carefully detach a stream from any server
This adds a helper call for detaching a DnsServer from a DnsStream if
the latter is the "default" stream of the server.
Also, let's unref the stream in dns_stream_stop() rather than
dns_stream_free(): as soon as our stream is disconnected by stopping
there's really no need to keep it as default stream for the server
around.
Since dns_stream_free() calls dns_stream_stop() we can remove it from
the former.
resolved: take particular care when detaching DnsServer from its default stream
DnsStream and DnsServer have a symbiotic relationship: one DnsStream is
the current "default" stream of the server (and thus reffed by it), but
each stream also refs the server it is connected to. This cyclic
dependency can result in weird situations: when one is
destroyed/unlinked/stopped it needs to unregister itself from the other,
but doing this will trigger unregistration of the other. Hence, let's
make sure we unregister the stream from the server before destroying it,
to break this cycle.
resolved: don't read packet from DnsStream on on_stream_complete() of DnsTransaction
We register an on_packet() handler anyway, which is called first.
There's hence no need to check in on_stream_complete() again, as it is
already taken by that time.
resolved: be more careful with types in dns_stream_writev()
Let's not name a variable of type ssize_t "r". We usually use "r" for
return values of API calls that return some kind of error as in int.
This creates a lot of confusion if used differently here, which actually
resulted in connect()'s return value being assigned to this mistyped "r"
by accident.
Let's rename the variable "m" hence, and not use it for connect() return
values.
systemctl: be nice to users and give hint how to specify "-.mount"
https://bugzilla.redhat.com/show_bug.cgi?id=1656639
Using "--" is a trick that is hard to discover. Let's give users a hint:
$ build/systemctl status -.service
build/systemctl: invalid option -- '.'
Hint: to specify units starting with a dash, use "--":
build/systemctl [OPTIONS...] {COMMAND} -- -.service ...
I use program_invocation_name because that's what getopt seems to use.
"::" is used in the option string so that getopt doesn't complain about
a missing argument in case somebody passes "-." as the argument. After all
"." is not a real option.
projects / thirdparty / systemd.git / log
