Re: [systemd-devel] Alternatives to RequiresOverridable= ?
On 10.04.2021 03:07, Cameron Sparr wrote: > Hello, I work for Amazon ECS and I’ve been working on a change to one of our > systemd services. From what I could tell in documentation I found online, it > seemed that RequiresOverridable= was the perfect fit for our use-case. > > > When I built a package using this field, however, I got a message saying that > this option is obsolete, which led me to this mailing list message: > https://lists.freedesktop.org/archives/systemd-devel/2015-November/034880.html > > > So my question is, what would be the alternative to using > RequiresOverridable? What got our attention to use this flag was that user > input would be able to override the requirement, which is exactly what we > want. Does Requires= also provide that capability? From our testing it > _seems_ like it does but I don’t see it called out in the documentation > anywhere. > > > If it helps, I can describe our use-case below: > > > 1. We have a service that executes user-defined bash scripts on system > startup called (simplifying) cloud-final.service. > > 2. We have a service called ecs.service that runs the ecs daemon > service. This service’s configuration file is usually made by the user > scripts run in cloud-final.service > > 3. So we wanted to make sure ecs.service starts after > cloud-final.service. To accomplish this we put After=cloud-final.service in > ecs.service. > > 4. But now we would also like users to be able to override ecs.service > waiting for cloud-final.service to finish. Because cloud-final allows users > to execute arbitrary bash scripts they should be able to run “systemctl start > ecs” and the ecs service will start. > After= dependencies are relevant only for jobs that are currently present in job queue. If ecs.server does not pull in cloud-final.service with Wants= or Requires=, you can start it explicitly without any delay. Of course if when you request starting ecs.service the cloud-final.service is still being activated (its start job is active), then ecs.service will wait for activation to complete. There is no way around it I am aware of. > 5. So the solution we were going to do was split ecs into two services: > > a. ecs-ready.service which has After=cloud-final.service > > b. ecs.service which has RequiresOverridable=ecs-ready.service > Requires/Wants/RequiresOverridable= without After= is useless. And it sounds like you tested Requires= without After= when you say "it seems to work". RequiresOverridable= with After= would still attempt to start required unit and wait for it. It would have ignored failure to start required unit, but that is not what you want. > 6. The idea above being that normally ecs.service would start with > ecs-ready (and thus after cloud-final), but if the user explicitly requested > it could be started without having to wait for after cloud-final. > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Alternatives to RequiresOverridable= ?
Hello, I work for Amazon ECS and I’ve been working on a change to one of our systemd services. From what I could tell in documentation I found online, it seemed that RequiresOverridable= was the perfect fit for our use-case. When I built a package using this field, however, I got a message saying that this option is obsolete, which led me to this mailing list message: https://lists.freedesktop.org/archives/systemd-devel/2015-November/034880.html So my question is, what would be the alternative to using RequiresOverridable? What got our attention to use this flag was that user input would be able to override the requirement, which is exactly what we want. Does Requires= also provide that capability? From our testing it _seems_ like it does but I don’t see it called out in the documentation anywhere. If it helps, I can describe our use-case below: 1. We have a service that executes user-defined bash scripts on system startup called (simplifying) cloud-final.service. 2. We have a service called ecs.service that runs the ecs daemon service. This service’s configuration file is usually made by the user scripts run in cloud-final.service 3. So we wanted to make sure ecs.service starts after cloud-final.service. To accomplish this we put After=cloud-final.service in ecs.service. 4. But now we would also like users to be able to override ecs.service waiting for cloud-final.service to finish. Because cloud-final allows users to execute arbitrary bash scripts they should be able to run “systemctl start ecs” and the ecs service will start. 5. So the solution we were going to do was split ecs into two services: a. ecs-ready.service which has After=cloud-final.service b. ecs.service which has RequiresOverridable=ecs-ready.service 6. The idea above being that normally ecs.service would start with ecs-ready (and thus after cloud-final), but if the user explicitly requested it could be started without having to wait for after cloud-final. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SysGenID: a system generation id provider
Hi all, This RFC is a continuation of a longer kernel patch thread https://lkml.org/lkml/2021/3/8/677 where we originally thought such a mechanism belongs. Ultimately, consensus there was that this mechanism would be better suited in userspace, so systemd was an obvious first choice. Current proposal: * As GitHub Issue here: https://github.com/systemd/systemd/issues/19269 * An example PoC here: https://github.com/acatangiu/sysgenid-dbus * Described in this email as follows: # SysGenID: a system generation id provider ## Background and problem The System Generation ID feature is required in virtualized or containerized environments by applications that work with local copies or caches of world-unique data such as random values, uuids, monotonically increasing counters, cryptographic nonces, etc. Such applications can be negatively affected by VM or container snapshotting when the VM or container is either cloned or returned to an earlier point in time. Solving the uniqueness problem strongly enough for cryptographic purposes requires a mechanism which can deterministically reseed userspace PRNGs with new entropy at restore time. This mechanism must also support the high-throughput and low-latency use-cases that led programmers to pick a userspace PRNG in the first place; be usable by both application code and libraries; allow transparent retrofitting behind existing popular PRNG interfaces without changing application code; it must be efficient, especially on snapshot restore; and be simple enough for wide adoption. ## Solution Introduce a mechanism that standardizes an API for applications and libraries to be made aware of uniqueness breaking events such as VM or container snapshotting, and allow them to react and adapt to such events. The System Generation ID is meant to help in these scenarios by providing a monotonically increasing u32 counter that changes each time the VM or container is restored from a snapshot. The `sysgenid` service exposes a monotonic incremental System Generation u32 counter via the DBus `com.RFC.sysgenid` accessible at `/com/RFC/sysgenid`. It provides asynchronous SysGen counter update notifications, as well as counter retrieval and confirmation mechanisms. The counter starts from zero when the service is started and monotonically increments every time the system generation changes. Userspace applications or libraries can (a)synchronously consume the system generation counter through the provided DBus interface, to make any necessary internal adjustments following a system generation update. The provided DBus interface operations can be used to build a system level safe workflow that guest software can follow to protect itself from negative system snapshot effects. System generation changes are driven by userspace software through a dedicated DBus method. ### Warning SysGenID alone does not guarantee complete snapshot safety to applications using it. A certain workflow needs to be followed at the system level, in order to make the system snapshot-resilient. Please see the "Snapshot Safety Prerequisites" section below. ## SysGenID DBus interface Terminology - `watcher` - a client using the SysGenID service _watching_ for system generation changes. - `untracked watcher` - default state for all clients. For a client to be tracked it has to explicitly opt-in by confirming back to the service the correct _system generation counter_. - `tracked watcher` - a client that is tracked by the service. Such a watcher is considered `up-to-date` only after confirming back to the service the correct _system generation counter_. Once tracked, a client is only _untracked_ when closing its connection to the DBus bus. - `outdated watcher` - a _tracked_ client that whose tracking has lived through a system generation change, but has not (yet) confirmed back to the service the correct _system generation counter_. **Methods:** - `GetSysGenCounter` - returns latest system generation counter. - `AckWatcherCounter` - marks the client/watcher to be tracked for ACKs, is also used by the watcher to confirm/ack the correct _sys gen counter_ to the service after every generation change so the service keeps correct track of it as `outdated` or `up-to-date`. Will error if client/watcher confirms/acks the wrong _sys gen counter_. - `CountOutdatedWatchers` - returns the number of current number of _outdated tracked watchers_. A value of `zero` can be interpreted as the system being fully re-adjusted after a generation change. - `TriggerSysGenUpdate` - triggers a generation update (should be a privileged operation). **Signals:** - `NewSystemGeneration` - system generation change notification, also carries new _sys gen counter_. - `SystemReady` - notification sent out when all tracked watchers have _acked_ the new _sys gen counter_. In other words, when all tracked software has adjusted to the new environment. The service
Re: [systemd-devel] .local searches not working
On Sat, Apr 10, 2021, 02:02 Mantas Mikulėnas wrote: > On Fri, Apr 9, 2021, 22:28 Phillip Susi wrote: > >> >> Silvio Knizek writes: >> >> > So in fact your network is not standard conform. You have to define >> > .local as search and routing domain in the configuration of sd- >> > resolved. >> >> Interesting... so what are you supposed to name your local, private >> domains? > > > .home.arpa is reserved for that purpose by IANA (as part of the Homenet > work, but explicitly stated that its usage is not limited to Homenet > protocols). > Er, I think I mixed up IANA and IETF there. It should be the latter, I think. > Though if you own a public domain there's nothing wrong with using a > subdomain of it for your private LAN, either. > > I believe Microsoft used to ( or still do? ) recommend using >> .local to name your domain if you don't have a public domain name, so >> surely I'm not the first person to run into this? > > > It could be that at some point they did. I've seen Active Directory > domains named "university.local" (even though they *did* have a public > domain...) But IIRC they went back on that recommendation. > > Why does >> systemd-resolved not fall back to DNS if it can't first resolve the name >> using mDNS? That appears to be allowed by the RFC. >> > > Simply falling back for each individual query is probably not desirable > because it would also leak local hostnames for people who *do* use mDNS. > > Systemd-resolved could implement the "check if local. SOA exists" probe > that AFAIK Apple does, I think there was a github thread about it... > > ... Actually, if you manually set an interface's search domain in resolved > to "local", doesn't that make it start using DNS for this domain? I cannot > test right now, but I'm *sure* I've seen something like that in resolved's > docs. > >> ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .local searches not working
On Fri, Apr 9, 2021, 22:28 Phillip Susi wrote: > > Silvio Knizek writes: > > > So in fact your network is not standard conform. You have to define > > .local as search and routing domain in the configuration of sd- > > resolved. > > Interesting... so what are you supposed to name your local, private > domains? .home.arpa is reserved for that purpose by IANA (as part of the Homenet work, but explicitly stated that its usage is not limited to Homenet protocols). Though if you own a public domain there's nothing wrong with using a subdomain of it for your private LAN, either. I believe Microsoft used to ( or still do? ) recommend using > .local to name your domain if you don't have a public domain name, so > surely I'm not the first person to run into this? It could be that at some point they did. I've seen Active Directory domains named "university.local" (even though they *did* have a public domain...) But IIRC they went back on that recommendation. Why does > systemd-resolved not fall back to DNS if it can't first resolve the name > using mDNS? That appears to be allowed by the RFC. > Simply falling back for each individual query is probably not desirable because it would also leak local hostnames for people who *do* use mDNS. Systemd-resolved could implement the "check if local. SOA exists" probe that AFAIK Apple does, I think there was a github thread about it... ... Actually, if you manually set an interface's search domain in resolved to "local", doesn't that make it start using DNS for this domain? I cannot test right now, but I'm *sure* I've seen something like that in resolved's docs. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .local searches not working
Silvio Knizek writes: > So in fact your network is not standard conform. You have to define > .local as search and routing domain in the configuration of sd- > resolved. Interesting... so what are you supposed to name your local, private domains? I believe Microsoft used to ( or still do? ) recommend using .local to name your domain if you don't have a public domain name, so surely I'm not the first person to run into this? Why does systemd-resolved not fall back to DNS if it can't first resolve the name using mDNS? That appears to be allowed by the RFC. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .local searches not working
Am Freitag, dem 09.04.2021 um 14:27 -0400 schrieb Phillip Susi: > What special treatment does systemd-resolved give to .local domains? > The corporate windows network uses a .local domain and even when I point > systemd-resolved at the domain controller, it fails the query without > bothering to ask the dc saying: > > resolve call failed: No appropriate name servers or networks for name > found Well, .local is by definition special as it is reserverd for MulticastDNS [1]. The man page [2] itself says > Multi-label names with the domain suffix ".local" are resolved using > MulticastDNS on all local interfaces where MulticastDNS is enabled. > As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6 > address lookups are sent via IPv6. > > Queries for multi-label names are routed via unicast DNS on local > interfaces that have a DNS server configured, plus the globally > configured DNS servers if there are any. Which interfaces are used > is determined by the routing logic based on search and route-only > domains, described below. Note that by default, lookups for domains > with the ".local" suffix are not routed to DNS servers, unless the > domain is specified explicitly as routing or search domain for the > DNS server and interface. This means that on networks where the > ".local" domain is defined in a site-specific DNS server, explicit > search or routing domains need to be configured to make lookups work > within this DNS domain. Note that these days, it's generally > recommended to avoid defining ".local" in a DNS server, as RFC6762 > reserves this domain for exclusive MulticastDNS use. So in fact your network is not standard conform. You have to define .local as search and routing domain in the configuration of sd- resolved. BR Silvio [1] https://tools.ietf.org/html/rfc6762#section-3 [2] https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] .local searches not working
What special treatment does systemd-resolved give to .local domains? The corporate windows network uses a .local domain and even when I point systemd-resolved at the domain controller, it fails the query without bothering to ask the dc saying: resolve call failed: No appropriate name servers or networks for name found ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
