On Tue, Apr 17, 2018 at 04:01:04PM -0400, R P Herrold wrote: > On Tue, 17 Apr 2018, Zbigniew Jędrzejewski-Szmek wrote: > > > On Tue, Apr 17, 2018 at 12:41:15PM -0400, R P Herrold wrote: > > > To make this work, we could either require that maintainers of A add > > Requires(post): B, or delay the starting of services until the end > > of the transaction, using a transfiletrigger. This second approach > > is much more attractive. Actually we already od a delayed > > 'systemctl daemon-reload' after the transaction, and we could start > > the services after that. > > Thank you ... but: > > you trimmed off and did not respond to the harder part of my > real-world example Yep, I did. > herrold earlier: > > I know I need to go in and manually create and add files > > like: > > /etc/systemd/system/var-ftp-pub-nfs-mirror2.mount > > > > and then link in that file in: > > /etc/systemd/system/machines.target.wants/ > > > > to get NFS working as I want -- I cannot imagine that** any > > ** install tool knows how to read my desires as a deploying > > owner > > which in this case is a RO NFS mount of a third party SAN > device, and which contains site specific matter needed for an > install needs to access to be useful > > > There are companion files, such as one with a RW: > /etc/systemd/system/home-nfs.mount > and more, and the RW case is much 'harder' to solve > (rootsquash, NFSv4, restricted IP ranges, more). This is for > a workstation class unit Yes, I don't think we could deal with arbitrary complexity here. But all that stuff is not something that would be subject to being enabled by default anyway. And... ... the guidelines say that "if a service does not require manual configuration to be functional and does not listen on a network socket for connections originating on a separate physical or virtual machine [...] may be enabled by default" or "Some services which are permitted to be enabled by default as specific exceptions." So the default presets are mostly for services which are understood to be "safe" (for some definition of safe, it's always a judgement call, e.g. sshd is enabled by default). Another thing to consider is that after a service has been enabled, it is in principle always possible for the service to be started: - first, a machine might be restarted because of a power failure, kernel panic, or a user tripping over a cable, in which case the service will be started on reboot - second, a transaction might be started which pulls in the target which pulls in the service in question, and the service might be started as a side effect. So if a service is enabled by default and needs tuning before being started, this tuning better happen *before* the service is enabled, i.e. before the package is installed, if it will be enabled in %post. > How is chasing down a rabbit hole of unknowable configuration > possibilities, to start things during deployment, and before > hardening even vaguely 'solveable' even with unlimited ** > packager ** effort? Augeas sort of tried to do this, and got > mired in complexity quicksand. Trying to enable install time > startups is in no way a 'costless' decision and adding new and > ill-defined 'requirements' for unclear reasons will tend to > reduce packager willingness to participate > > > As I pointed out, install order matters, and in testing alone, > the big O() complexity testing matrix explodes at a O(N^M) > rate. That is, it is simply untestable in very short order > > And just WHY do we want to start services during deployment, > and before hardening? Why would we WANT to enable services > _before_ application of potential security updates recognized > and released after a media freeze? I see two scenarios: - one, you install from an image, w/o pulling updates from the network, restart the machine, and pull in updates. - two, you install w/ network access, pulling updates for any packages for the initial installation. In the second case, updated packages are installed, and in the first case, a reboot happens before the update, so any enabled services will be started. In both scenarios starting them immediately after installation doesn't change things. > I do not understand the use case at all The use case is that for simple packages, it's simpler for the user if the service is available immediately. My initial example with gpm is actually good here: do "sudo dnf install -y gpm", move mouse, voilà. Also the case from https://bugzilla.redhat.com/show_bug.cgi?id=1545027: a user installs some daemon for smartcards, and expects it to be functional without rebooting. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
